Currently sys-kernel/gentoo-sources version numbers and slot numbers are the same - for example, sys-kernel/gentoo-sources-6.1.53-r1:6.1.53-r1 IMHO this has no valid use case! Typically someone using kernel 6.1.53 is following the kernel.org Long Term Stable kernel series, which is 6.1.x, with x increasing as the kernel devs release new fixes. I suggest the slot number should be just the two digits that define the kernel release rather than include the fix level, let alone the Gentoo patch level! Specifically, in the above case, it would be sys-kernel/gentoo-sources-6.1.53-r1:6.1 enabling someone who wants to use LTS to emerge sys-kernel/gentoo-sources:6.1 and automatically pick up the next LTS release. (An alternative would be to use slots called "mainline", "stable" and "longterm", but kernel.org often has two "stables" and several "longterm"s, so the kernel release is more useful Reproducible: Always See also Gentoo forums item https://forums.gentoo.org/viewtopic-t-1165476-highlight-.html
Just to be clear, I'm not restricting the idea of 2-level slots just to the LTS kernel - all kernels should get the 2-digit slot, so current stable is :6.5, current mainline development is :6.6 and so forth.
This is complete and will propagate as new gentoo-sources kernels enter the tree $ equery list -p gentoo-sources * Searching for gentoo-sources ... <cut> [-P-] [ ~] sys-kernel/gentoo-sources-5.15.136:5.15 <cut> [-P-] [ ~] sys-kernel/gentoo-sources-6.1.59:6.1 <cut> [-P-] [ ~] sys-kernel/gentoo-sources-6.5.8:6.5
Wow, that was quick. Thanks!
IMHO, I preferred the original method as I can keep a certain kernel sources installed by slot instead of messing with package.{un,}mask I wish this could be reverted.
(In reply to Brian Evans from comment #4) > IMHO, I preferred the original method as I can keep a certain kernel sources > installed by slot instead of messing with package.{un,}mask > > I wish this could be reverted. +1
@Paul Gover, >>Currently sys-kernel/gentoo-sources version numbers and slot numbers are the same - for example, sys-kernel/gentoo-sources-6.1.53-r1:6.1.53-r1 IMHO this has no valid use case! The use case of this is you being able to have multiple kernels emerged, for example when testing a new stable kernel, you want to keep the old one. It looks like it'll no longer be possible to have multiple kernels from the same line emerged after this change which is NOT OK. Best Regards, Georgi
Without any comment on the actual decision, I request that people comment with respect for the people who made the decision and with actual arguments, rather than simply "it broke my spacebar heating".
(In reply to Sam James from comment #7) > Without any comment on the actual decision, I request that people comment > with respect for the people who made the decision and with actual arguments, > rather than simply "it broke my spacebar heating". And *I'm* sorry for the tone here, as it wasn't helpful. What I should've said was that I think focusing on the specific use cases that are impacted here is useful, rather than focusing on just reverting things, because that makes it very hard to ever change anything. Let's give this a bit of time to settle down post-revert which Mike is working on now, and then try sketch up a table for the diff. use cases and possible options. There's a few bits we could do on the Portage side (not just variance in SLOT which is the obvious but tricky answer) to make life easier here too.
Since I thought Paul Gover's idea was very good I encouraged him to write a bug and feel a little complicit. First of all I would like to thank Mike for the very fast implementation and then I would like to ask all involved to trust in our developers who certainly take all concerns very seriously. When Sam says that "There's a few bits we could do on the Portage side [...]" I am convinced that the issue will be solved satisfactorily for everyone. (I will crosspost this statement in Bug and Forum)
