Summary: | ebuild providing virtual/linux-sources | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Florian Huber <florian.huber> |
Component: | New packages | Assignee: | x86-kernel (DEPRECATED) <x86-kernel> |
Status: | RESOLVED WONTFIX | ||
Severity: | enhancement | CC: | steel300 |
Priority: | High | Keywords: | EBUILD |
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
$PORTDIR_OVERLAY/sys-kernel/dummy-sources/dummy-sources-1.0.ebuild
Added IUSE="" as said in the ebuild howto dummy-sources-1.0-r1.ebuild dummy-sources-1.0-r1.ebuild (FIX) dummy-sources-1.0-r1.ebuild (FIX, really!) |
Description
Florian Huber
2003-07-27 09:54:53 UTC
Created attachment 15082 [details]
$PORTDIR_OVERLAY/sys-kernel/dummy-sources/dummy-sources-1.0.ebuild
I put it in ~arch to prevent dumb user from installing it accidently :)
Created attachment 15088 [details]
Added IUSE="" as said in the ebuild howto
Created attachment 15098 [details]
dummy-sources-1.0-r1.ebuild
Fixed futher syntax "errors" in the ebuild.
`lintool --show-details --ebuild dummy-sources-1.0-r1.ebuild` now only displays
a warning because of the empty DEPEND var.
Hope it is gentoo conform now :)
Created attachment 15099 [details]
dummy-sources-1.0-r1.ebuild (FIX)
re-upload (forgot to save file locally)
Created attachment 15100 [details]
dummy-sources-1.0-r1.ebuild (FIX, really!)
Sorry, this should be the latest update for a while.
Admins, feel free to delete former attachements.
Hmm, to custom patch your kernel you need a base, and would that happen to be vanilla-sources or development-sources? As they provide these virtuals, is this still needed? Sometimes there were no vanlilla/development sources for the kernel I wanted to use. Especially if I wanted to try "brandnew" kernels. The dummy sources would also prevent you from downloading the latest (ebuild-) kernel sources when doing a world-update, even if you don't want them. This isn't a bad idea for a single user, but I doubt that it would be a good addition to the portage tree. We're currently trying to cut down on the number of sources in sys-kernel, this wouldn't really benefit anyone except those who ahve already implemented it in some way. Of course, this is of minor use for the average user, but there may be some experienced users looking a clean way to use their kernel sources, which the dummy-ebuild does. The experienced people doing custom patched kernels have usually found a way to implement this. Adding this would destroy some of the sanity checks portage provides. In my opinion, it puts too much trust in the user to make sure they have a kernel tree somewhere. With the addition of the new kernel-2 eclass, I think more issues would pop up. John, would you mind commenting on this? Leaving out. Those that need it have it already or came up with an alternative they like. |