The purpose of homebrew-sources is to remove the need to update *-sources when new kernel version becomes available. It leaves the taking care of kernel to user. It also doesn't install anything.
Created attachment 58783 [details] homebrew-sources-2.6.99.ebuild The ebuild.
not needed -> man portage, search for package.provided
package.provided locks it to a specific version. Doesn't work across the board, otherwise the ebuild wouldn't have existed prior (iow, if --inject sufficed, it would be the default).
package.provided messes things with alsa: nelchael ~ # echo "sys-kernel/vanilla-sources-2.6.11.8" >> /etc/portage/package.provided nelchael ~ # emerge -upvD world These are the packages that I would merge, in order: Calculating world dependencies ti !!! All ebuilds that could satisfy "~media-sound/alsa-headers-1.0.9_rc3" have been masked. !!! One of the following masked packages is required to complete your request: - media-sound/alsa-headers-1.0.9_rc3 (masked by: package.mask) For more information, see MASKED PACKAGES section in the emerge man page or section 2.2 "Software Availability" in the Gentoo Handbook. !!! (dependency required by "media-sound/alsa-driver-1.0.9_rc3" [ebuild]) !!! Problem with ebuild media-sound/alsa-utils-1.0.8 !!! Possibly a DEPEND/*DEPEND problem. !!! Depgraph creation failed. nelchael ~ #
Oh, never used it. I assumed sys-kernel/vanilla-sources or >=sys-kernel/vanilla-sources-x.y.z would be allowed. I dislike the idea of empty packages in the tree.
metapkg proposal is basically empty nodes (in reality, empty packages abused for indirection). then there also is app-portage/envtest. :) Empty ebuilds normally, yeah, I agree. In this case, I find it useful homebrew pretty much gets me out of all kernel dep crud when it comes to the tree. It's the best way I know of to dodge out of having portage try and manage that bit for me, while not hacking/special casing it.
Comment #5: =sys-kernel/vanilla-sources-x.y.z in package.provided _should_ be allowed, this is an alsa ebuild then. :-(
Err.. I meant "this is an alsa ebuild BUG then". I will submit a new one.
Jakub Moc: Wrong
Comment #9: Hmm, wrong - but what
Comment #9: Hmm, wrong - but what´s wrong? echo "sys-kernel/vanilla-sources-2.6.11.8" >> etc/portage/profile/package.provided is not supposed to work?
But it doesn't: nelchael ~ # emerge -upvD world These are the packages that I would merge, in order: Calculating world dependencies ...done! [ebuild U ] media-sound/alsa-headers-1.0.9_rc3 [1.0.8] 1,965 kB [ebuild N ] sys-kernel/gentoo-sources-2.6.11-r8 -build -doc -symlink (-ultra1) 246 kB [ebuild N ] media-sound/alsa-driver-1.0.9_rc3 -debug -doc -oss 0 kB [ebuild U ] media-libs/alsa-lib-1.0.9_rc3 [1.0.8] -doc -jack 674 kB Total size of downloads: 2,885 kB nelchael ~ # cat /etc/portage/profile/package.provided sys-kernel/vanilla-sources-2.6.11.8 nelchael ~ #
# mkdir -p /etc/portage/profile # echo vanilla-sources-2.6.11 >> /etc/portage/profile/package.provided # echo virtual/linux-sources vanilla-sources >> /etc/portage/profile/virtuals # echo virtual/alsa vanilla-sources >> /etc/portage/profile/virtuals This is the minimum needed. If there was an entry for the kernel in system, it would have to be negated as well. Also, any new virtual that is added to the kernels must updated in /etc/portage/profile/virtuals too.
Woops. "sys-kernel/" needs to be added to before all the occurrences of "vanilla-sources". Also, the report in comment #4 is most definitely not a bug with the alsa-driver ebuild. The user has intentionally masked alsa-driver for consistency because the kernel provides it.
Comment #12: Oh well, I see. I guess that package.provided and the related stuff would deserve some more BFU friendly docs. ;-) Anyway, I vote for homebrew as it would save all the trouble.
I've talked with johnm before about this and he seemed to be fine with adding this.
This is what /etc/portage/profile/package.provided is for...
Yep, neither solution (/etc/portage or having an ebuild) is nice, but it would be nice to keep such hacks outside of the portage tree when dealing with kernels that aren't in portage. http://gentoo-wiki.com/HOWTO_Install_kernel_sources_manually
(In reply to comment #16) > This is what /etc/portage/profile/package.provided is for... Did You test it with *-sources packages? nelchael ~ # emerge -tupvD world These are the packages that I would merge, in reverse order: Calculating world dependencies ...done! [nomerge ] media-sound/alsa-utils-1.0.9a +nls [nomerge ] media-libs/alsa-lib-1.0.9 -doc -jack [ebuild N ] media-sound/alsa-driver-1.0.9b -debug -doc -oss 1,972 kB [ebuild N ] sys-kernel/gentoo-sources-2.6.11-r11 -build -doc -symlink (-ultra1) 255 kB Total size of downloads: 2,228 kB nelchael ~ # cat /etc/portage/profile/package.provided sys-kernel/vanilla-sources-2.6.11.12 I'm still for homebrew-sources :) It's easier and cleaner.
sys-kernel/gentoo-sources-2.6.10 works fine for me root@vapier 0 ~ # emerge alsa-utils -ep | egrep '(kernel|alsa)' [ebuild N ] sys-kernel/linux-headers-2.6.11-r1 [ebuild N ] media-sound/alsa-headers-1.0.9 [ebuild N ] media-libs/alsa-lib-1.0.9 [ebuild N ] media-plugins/alsa-jack-1.0.9 [ebuild N ] media-sound/alsa-utils-1.0.9a root@vapier 0 ~ # cat /etc/portage/profile/package.provided sys-kernel/gentoo-sources-2.6.10
mkdir /etc/portage/profile echo "sys-kernel/vanilla-sources-2.6.99" >> /etc/portage/profile/package.provided echo "virtual/alsa sys-kernel/vanilla-sources" >> /etc/portage/profile/virtuals echo "virtual/linux-sources sys-kernel/vanilla-sources" >> /etc/portage/profile/virtuals just look at the link :)
You have virtuals in /etc/portage/profile/ :) I didn't. WORKSFORME too :) That it works doesn't change that I prefer the homebrew-sources solution. It saves the trouble of tracking any new virtual that pops up with newer kernels.
