| Summary: | sys-kernel/vanilla-eol-sources - ? | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | C. Wijtmans <cj.wijtmans> |
| Component: | New packages | Assignee: | Default Assignee for New Packages <maintainer-wanted> |
| Status: | RESOLVED WONTFIX | ||
| Severity: | enhancement | CC: | gregkh, kernel |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| See Also: | https://bugs.gentoo.org/show_bug.cgi?id=497994 | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
C. Wijtmans
2013-08-05 10:02:55 UTC
how about slotting the EOL kernels in the vanilla-sources package to EOL? is that possible? how about slotting the EOL kernels in the vanilla-sources package to EOL? is that possible? Greg, what do you think as upstream? Imho, it does not make much sense. (In reply to C.J. Wijtmans from comment #0) > I would like to see a vanilla-eol-sources package for the EOL kernels. Two packages should be avoided if possible. > There are a few good reasons for this. Note that there are also bad reasons; for example, security. > One for example the private nvidia drivers are most likely ready for the EOL sources. > Also they are more stable most likely than updating to the first source of a new cycle. They are very ready for the LTS releases, which are more stable than EOL. > We can advice people to use the EOL sources instead of the normal vanilla sources. This doesn't sounds like a good idea, both upstream and downstream we want people to upgrade away from them. (In reply to C.J. Wijtmans from comment #2) > how about slotting the EOL kernels in the vanilla-sources package to EOL? is > that possible? If we would at all do this we would add these as masked because of those bad reasons; but if we do that, consider that work to unmask it compared to the work to bring a version back using your local overlay is rather minimal. EBUILD="/usr/local/portage/sys-kernel/vanilla-sources/vanilla-sources-X.Y.Z.ebuild" ; cp $(equery w sys-kernel/vanilla-sources) ${EBUILD} ; ebuild ${EBUILD} manifest Now, if we look for a way for it to become easier than to mask them; they could for instance be placed on the graveyard overlay: http://www.gossamer-threads.com/lists/gentoo/dev/268298 CC-ed the kernel team for a second opinion. No, this isn't ok, those trees are EOLed for a reason, and no security updates are there for them, and they are now obsolete and should not be used at all. @ C.J. Wijtmans: http://blogs.gentoo.org/ago/2013/08/30/use-an-eol-kernel/ I still wish to have some kind of package or slot where the nvidia driver is supporting the kernel.. any ideas? The vanilla kernels do not care about the closed-source nvidia drivers, sorry, you are on your own there, I am not allowed to help you out at all. As was pointed out, you can provide your own overlay for this, or use the gentoo-sources package and disable the added-on patches (with the new config option), but the vanilla-sources packages are not going to do this, sorry. A stable 3.4.60 would cover all versions of nvidia-drivers, but then you'd still be stuck with ancient versions of xorg-server. i am talking nvidia supporting the kernel not the other way around. (In reply to C.J. Wijtmans from comment #10) > i am talking nvidia supporting the kernel not the other way around. I don't see what you mean. |
