It would be nice to have a "lts" suffix on the slot name for sys-kernel/*sources packages which are based on the lts series on https://www.kernel.org/. This would greatly improve the workflow on kernel bumps in corporate environments. Reproducible: Always
Hello, this has been requested a few times. Note that the "based on the lts series" doesn't reflect upstream; a series could or couldn't become lts at a random point in time, which means we're going to have to deal with slot moves. As for a "suffix on the slot name", how would that work? Wildcard is unsupported; so, that would mean we need to change PMS and/or PM first to support that... Virtuals have been suggested as a solution to this, but nobody made them yet.
If i understand you correctly, a (kernel.org) series gets "promoted" as a LTS series at some point during the development on the series. Taking the latest LTS 3.10.x as an example: -> 3.10.1, 3.10.2, 3.10.3, 3.10.x *ding* [LTS] 3.10.y I don't see a reason why this cannot be done with a slot layout like this: Starting with (3.10) 3.10.1, 3.10.2, 3.10.3 and once the series has been upgraded to an lts: (3.10lts) 3.10.10, 3.10.11, ... Of course, at some point the now old (pre-lts) slot 3.10 should be dropped.
(In reply to Johann Schmitz (ercpe) from comment #2) > If i understand you correctly, a (kernel.org) series gets "promoted" as a > LTS series at some point during the development on the series. Yes, and then there is two possible ways to perceive this; one is to use the slotmove functionality and regard the whole series as LTS, the other is to do what you suggest below and thus use a turn-around point where they suddenly start becoming lTS. > Taking the latest LTS 3.10.x as an example: > > -> 3.10.1, 3.10.2, 3.10.3, 3.10.x *ding* [LTS] 3.10.y > > I don't see a reason why this cannot be done with a slot layout like this: > > Starting with > (3.10) 3.10.1, 3.10.2, 3.10.3 > > and once the series has been upgraded to an lts: > (3.10lts) 3.10.10, 3.10.11, ... > > Of course, at some point the now old (pre-lts) slot 3.10 should be dropped. It's more like: (3.10.1) 3.10.1, (3.10.2) 3.10.2, (3.10.3) (3.10.10lts) 3.10.10, (3.10.11lts) 3.10.11 But what is the gain if there is no wildcard functionality? There needs to be a good reason to have this, otherwise it only results in some unintended complications at no gain; like stable users switching between lts and non-lts all the time, our need to track and override the slots, users wanting to wildcard it but not being able to do so because the feature lacks, ...
(In reply to Tom Wijsman (TomWij) from comment #3) > Yes, and then there is two possible ways to perceive this; one is to use the > slotmove functionality and regard the whole series as LTS, the other is to > do what you suggest below and thus use a turn-around point where they > suddenly start becoming lTS. I don't think that slotmoving the pre-lts ebuild to a lts slot would be a good thing. Since they aren't lts'ed yet by upstream, they shouldn't been marked as. > It's more like: > > (3.10.1) 3.10.1, (3.10.2) 3.10.2, (3.10.3) > (3.10.10lts) 3.10.10, (3.10.11lts) 3.10.11 From https://www.kernel.org/category/releases.html: The whole 3.10 branch is a LTS branch. So we would see a 3.10 slot as long as we don't have a lts release in 3.10 and later another branch called 3.10lts. Since all further 3.10 release are long-term supported, they go into the 3.10lts slot. The 3.10 slot could be dropped as soon as the first 3.10 lts version is released or after a period where 3.10 and 3.10 co-exist. There will be the situation that we have stable ebuilds in lts slots and in (higher) non-lts slots. But this isn't different from what we have with other packages. > But what is the gain if there is no wildcard functionality? > > There needs to be a good reason to have this, otherwise it only results in > some unintended complications at no gain; like stable users switching > between lts and non-lts all the time, our need to track and override the > slots, users wanting to wildcard it but not being able to do so because the > feature lacks, ... To be honest, i don't see why we would need additional features in portage for this.
You want to improve the workflow on kernel bumps in corporate environments. Fair enough. Let's just start understanding why corporate environments opt for following lts. This is for a huge variety of reasons (among which project development planings, qualifications...) that are very likely to be still valid when a new lts happens. => If my company opts for 3.4 in the < 3.10 times, my company will not upgrade to 3.10 at the time 3.10 is declared lts. As a matter of fact, if I want to actually improve the workflow on kernel bumps, I'll simply push >=sys-kernel/ck-sources-3.5 in package.mask and wait until a decision is made to upgrade to whatever higher one.
(In reply to Eric F. GARIOUD from comment #5) > As a matter of fact, if I want to actually improve the workflow on kernel > bumps, I'll simply push >=sys-kernel/ck-sources-3.5 in package.mask and wait > until a decision is made to upgrade to whatever higher one. Your >=sys-kernel/ck-sources-3.5 mask would still catch everything higher or equal 3.5. It doesn't matter if it matches 10 versions in 10 slots or 10 versions in 3 slots... I don't see how this would change anything in the existing workflow except that one can easily spot whether version x is lts or not without opening kernel.org.
I had the same idea some time ago. Probably slots are not the best way to deal with it. How about adding a virtual/linux-lts? virtual/linux-lts-3.10.ebuild would include this: SLOT=3.10 RDEPEND=">=sys-kernel/gentoo-sources-3.10 <sys-kernel/gentoo-sources-3.11"
(In reply to Johann Schmitz (ercpe) from comment #4) > I don't think that slotmoving the pre-lts ebuild to a lts slot would be a > good thing. Since they aren't lts'ed yet by upstream, they shouldn't been > marked as. LTS happens on the branch, not on individual versions; therefore, both solutions are equally valid. The difference lies in when to do it: 1. The moment it is announced? 2. The moment it is marked? 3. Neither moment and just mark the whole branch. This also could become tricky when we miss the announcement or marking ourselves, while this might not be a huge problem with gentoo-sources or vanilla-sources; I guess some other sources will follow too late. > > It's more like: > > > > (3.10.1) 3.10.1, (3.10.2) 3.10.2, (3.10.3) > > (3.10.10lts) 3.10.10, (3.10.11lts) 3.10.11 > > From https://www.kernel.org/category/releases.html: The whole 3.10 branch is > a LTS branch. That's why I thought slotmoving could make sense hree. > So we would see a 3.10 slot as long as we don't have a lts release in 3.10 > and later another branch called 3.10lts. Since all further 3.10 release are > long-term supported, they go into the 3.10lts slot. Only the latest release is supported, there's no claim wrt to releases before that; there's the encouragement from Greg KH to "upgrade to the latest". Though, as for bug reporting and such, it becomes a bit more loose; it doesn't have to be the latest version there, but that on its own isn't a claim for the older versions to be supported. > The 3.10 slot could be dropped as soon as the first 3.10 lts version is > released or after a period where 3.10 and 3.10 co-exist. The slot could contain stable versions; so, this isn't always possible. And wrt to dropping policy; on gentoo-sources we try to keep the previous ~4 or so versions around, on vanilla-sources we only permit the last. > There will be the situation that we have stable ebuilds in lts slots and in > (higher) non-lts slots. Or like above, stable ebuilds in non-lts slots and in (higher) lts slots. > But this isn't different from what we have with other packages. Dunno, do you have examples? > > But what is the gain if there is no wildcard functionality? > > > > There needs to be a good reason to have this, otherwise it only results in > > some unintended complications at no gain; like stable users switching > > between lts and non-lts all the time, our need to track and override the > > slots, users wanting to wildcard it but not being able to do so because the > > feature lacks, ... > > To be honest, i don't see why we would need additional features in portage > for this. If there's no functionality to back up the change, then I repeat my question: What is the gain of doing this change? (In reply to Manuel Rüger from comment #7) > I had the same idea some time ago. > > Probably slots are not the best way to deal with it. > How about adding a virtual/linux-lts? > > virtual/linux-lts-3.10.ebuild would include this: > > SLOT=3.10 > RDEPEND=">=sys-kernel/gentoo-sources-3.10 > <sys-kernel/gentoo-sources-3.11" Exactly, this is an example of what I refer to at the end of Comment #1.
I think i have said everything to the other points, so i will jump to > What is the gain of doing this change? At home and on my server i almost always choose the latest version of the kernel sources (and often i don't care whether they are stable or not). At work this is quite a bit different: I can't reboot servers just because i feel that it's time to bump the kernel. Even using keyworded packages require some bureaucracy so i try to avoid it where i can. I know that keyworded packages aren't that bad and can be used in most cases without problems but that's the policy. Since the available versions in sys-kernel/gentoo-sources can change very fast, i stick with the official LTS version. Just to avoid that the installed version is keyworded or removed a week later. All i proposed was converting (3.0.101) ~3.0.101^bs (3.2.52) ~3.2.52^bs (3.2.53) ~3.2.53^bs (3.2.54) ~3.2.54^bs (3.4.72) ~3.4.72^bs (3.4.74) ~3.4.74^bs (3.4.75) ~3.4.75^bs (3.4.76) ~3.4.76^bs (3.4.9999) **3.4.9999^bs (3.9.11-r1) ~3.9.11-r1^bs (3.10.7) 3.10.7^bs (3.10.7-r1) 3.10.7-r1^bs (3.10.17) 3.10.17^bs (3.10.22) ~3.10.22^bs (3.10.24) ~3.10.24^bs (3.10.25) 3.10.25^bs (3.10.9999) **3.10.9999^bs (3.11.8) ~3.11.8^bs (3.11.9) ~3.11.9^bs (3.11.10) ~3.11.10^bs (3.11.9999) **3.11.9999^bs (3.12.4) ~3.12.4^bs (3.12.5) ~3.12.5^bs (3.12.6) ~3.12.6^bs (3.12.9999) **3.12.9999^bs into sth. like: (3.0) ~3.0.101^bs (3.2) ~3.2.52^bs ~3.2.53^bs ~3.2.54^bs (3.4) ~3.4.72^bs ~3.4.74^bs ~3.4.75^bs ~3.4.76^bs **3.4.9999^bs (3.9) ~3.9.11-r1^bs (3.10lts) 3.10.7^bs 3.10.7-r1^bs 3.10.17^bs ~3.10.22^bs ~3.10.24^bs 3.10.25^bs **3.10.9999^bs (3.11) ~3.11.8^bs ~3.11.9^bs ~3.11.10^bs **3.11.9999^bs (3.12) ~3.12.4^bs ~3.12.5^bs ~3.12.6^bs **3.12.9999^bs (of course 3.0, 3.2 and 3.4 would be suffixed with lts too). So it's more a cosmetic thing to help people to easily spot the lts releases.
(In reply to Johann Schmitz (ercpe) from comment #9) > (3.0) ~3.0.101^bs > (3.2) ~3.2.52^bs ~3.2.53^bs ~3.2.54^bs > (3.4) ~3.4.72^bs ~3.4.74^bs ~3.4.75^bs ~3.4.76^bs **3.4.9999^bs > (3.9) ~3.9.11-r1^bs > (3.10lts) 3.10.7^bs 3.10.7-r1^bs 3.10.17^bs ~3.10.22^bs ~3.10.24^bs > 3.10.25^bs **3.10.9999^bs > (3.11) ~3.11.8^bs ~3.11.9^bs ~3.11.10^bs **3.11.9999^bs > (3.12) ~3.12.4^bs ~3.12.5^bs ~3.12.6^bs **3.12.9999^bs > > So it's more a cosmetic thing to help people to easily spot the lts releases. Sure, but then you could just as well see it upstream; I think we should also fight for having the ability to wildcard slots. As then people could do :*lts or worst case :lts-* in order to accomplish this. Actually being able to select "the latest LTS" or just a certain branch (whether or not LTS) is something that's been requested more often; which brings up the discussion as to whether the slot should be like :3.12 or :3.12.6, we currently have the latter to make selecting a specific kernel more easy. The current model doesn't really allow us to switch us to the former (:3.12) as it unintended causes kernels to get removed and added on the fly; unless well, we enforce the user to consider to upgrade much more often. In fact, your server would have this very problem as well; because 3.10lts still gets new releases, so if you would emerge that branch you could have 3.10.25 this week but 3.10.26 next week. Thus, here we would rather want the slot to be 3.10.25lts. As said in earlier comments and above, being able to select "the latest LTS" would be nice to have; therefore I've filed bug #498106. We've still need to see as to whether making virtuals or changing slots is the better approach that fits here; we should definitely have one of both, but now the question is which one?
This is 7 years old, if this is still desired by someone, please suggest a solution and provide patches.
