Summary: | Shorten kernel (such as gentoo-sources) slot to two components | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Paul Gover <pmw.gover> |
Component: | Current packages | Assignee: | Gentoo Kernel Bug Wranglers and Kernel Maintainers <kernel> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | gentoo, grknight, josef64 |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
See Also: | https://bugs.gentoo.org/show_bug.cgi?id=285048 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Paul Gover
2023-10-15 10:56:57 UTC
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) |