On Wed, 27 Feb 2013 16:39:22 +0100 Marc Schiffbauer wrote: > Am Mittwoch, 27. Februar 2013, 13:49:52 schrieb Tom Wijsman: > > On Wed, 27 Feb 2013 13:07:38 +0100 > > > > Marc Schiffbauer wrote: > > > Am Dienstag, 26. Februar 2013, 19:13:18 schrieb Tom Wijsman: > > > > On Tue, 26 Feb 2013 18:37:16 +0100 (CET) > > > > > > > > As an easy way to keep a single kernel version from being > > > > unmerged by a kernel upgrade in Portage, I think. > > > > > > > > emerge gentoo-sources:3.7.9 > > > > > > But why would you want that? I think normally its more likely > > > that a user wants to stick to the seriens (e.g. :3.7) so that > > > he/she receives security updates as well as minor fixes. > > > > Because when sources unmerge, nothing can build against them and you > > also can't do a quick recompile if you do not want to do an upgrade. > > Indeed. But I thought of it only as a backup so that you can boot > your system in case a newer kernel won't. > > Why would you want to continue to use an outdated/insecure kernel > *from the same series* like 3.7*? No time yet to recompile a new kernel, a temporarily broken newer kernel (eg. nvidia-drivers doesn't work with it yet), and so on... Just one version off doesn't make that much of a difference in date and security. > > The majority of users doesn't upgrade on every single release, it is > > better to support them in their upgrade schedule instead of forcing > > them to upgrade or use more complex approaches to do what they want. > > Where would be the force? Uninstall of old sources would happen while > they are upgrading. It doesn't copy the sources, rebuild and install the kernel though. > I guess you are referring to a use case where user just upgrade > packages but would not like to restart the system. This is indeed a > use case for exact version slots. More is needed than to just restart their system, see my previous sentence. > Maybe both things yould coexist? Why not have both kinds of SLOTs > then? Hmm, subslots definitely sound interesting to use; only needs to figure out if that fits the case and whether users will understand them. > > > If you really wanted to stick to a particular version you can > > > always mask any version greater than that similar to what you > > > wrote yourself below: > > > > > > echo ">=sys-kernel/gentoo-sources-3.7" > > > >> /etc/portage/package.mask > > > > Doing this once per branch or for each version is a big difference. > > Indeed. The above mask would allow all 3.6* kernels rigtht? Assuming the version syntax doesn't get an extension that would undermine the version number, that masks everything in 3.7 and newer. > > > > > First, if you remove any gentoo-sources package it will never > > > remove the kernel or modules that have been built from it. So you > > > will always keep the kernel that may be important if a newer one > > > has problems for example. Regardless of removing the sources or > > > not. > > > > As stated above, that doesn't allow you to reproduce them quickly. > > That was not my intention. Please see above. But it can be the intention of other users. > > > > For small packages, it doesn't really matter how you do it; but > > setting up the kernel (copy config, make oldconfig) and compiling it > > make explicit (un)masking much more annoying than just keeping > > multiple versions within a branch around. > > Sorry I do not get it. What is your point here? Getting minor kernel > updates automatically without having to fiddle with masks/unmaks each > time is the goal here IMO. I'm not sure which part you didn't get, but be aware that the suggested SLOT approach does not keep multiple versions within a branch around; which forces the user to upgrade and therefore requires the user to do all that I said. Kernels release way too often for that, and it is not guaranteed that newer versions work so users will have to try them first; if one breaks for them, the new SLOT approach would have removed their old sources and therefore they would have to start all over with them if they have the need to rebuild their kernel or compile something against them. There is more than a single goal when talking about changing the SLOT syntax, especially for a bigger package like the kernel; users use it differently, yielding different reasons for different approaches to specify which version are selected and which versions are masked. Changing the SLOT syntax makes you need to consider what else changes, because it's not really worth pulling off something for a few users when it breaks the work flow for the majority of users. And note, we're pitting of only two or three use cases here, there are possibly more of them; I would love to see some regulars join the discussion. > So how about just add a new SLOTs for every stable long term kernel > release series like "3.4" and leaving current SLOTs as they are? Hmm, since stable kernel releases break less often, this might be reasonable. This introduces some inconsistency though, although that could be abused to make it clear to users that they are LTS series. I'll try to hear, I need to bug them about 3.4.3x stabilization too. With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : TomWij@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D