Genkernel seems to come with (included in the source tarball) diet-libc, busybox, udev, devfs, et al. Each with the correct version listed in the default config file. It does *not* include LVM2 or device-mapper, though it now has an --lvm2 option. Reproducible: Always Steps to Reproduce: 1. 2. 3. I care because I want to pass --lvm2 to genkernel from catalyst, but I've got no way to get the LVM2 and device-mapper source files into the chroot'd environment during the livecd-stage2 build.
We don't provide source as that would make a really bulky distribution package. Either emerge lvm in the chroot that runs genkernel *or* edit /etc/genkernel.conf and change the tarball specification there. Leaving bug open to get this documented...
I don't believe there is a way to update the genkernel.conf from a catalyst spec file, maybe I should open a catalyst bug? I'd actually be happier with the genkernel ebuild fetching *all* of the source tarballs required by the default genkernel.conf from a distfiles mirror at merge-time. That would make for a very small source distribution. Why include *any* of them in the genkernel distribution?
> Why include *any* of them in the genkernel distribution? Since they're guaranteed to work and are patched e.g. with cryptoloop support for busybox and other things needed for LiveCDs to work as they do.
> Since they're guaranteed to work and are patched e.g. with cryptoloop support for busybox and other things needed for LiveCDs to work as they do. I can respect that judgement call, but I think the argument is weak. You could easily fetch already-patched sources for some of the tools, and pristine sources for others. How about a command-line option to use a different file for genkernel.conf? Then I can at least accomplish something by using livecd/gk_mainargs and the new genkernel option. Or better yet, I can lobby for livecd/<kernelname>/genkernelconfig and let catalyst pass the option for me.
Okay, looking at the genkernel script it seems that genkernel.conf actually tells genkernel where to locate the rest of it's parts -- making the genkernel.conf very dependent on the version of genkernel. The before-suggested command-line option could be to source another "config" file after most of the genkernel modules are source'd. Thus re-defining only the variables the user wants to change -- almost like a config overlay.
Created attachment 49506 [details, diff] Adds additional config file support (badly) Patch against 3.1.0c (applies to 3.1.0e). Trivially adds --config= option to source an additional file containing variable assignments. The maintainers may want to change the name of the option and variables.
Ok, I think the best solution to this would be to get Portage to fetch these source tarballs if you have +lvm2 set in USE when you merge genkernel... How does that sound?
I think having the ebuild pull in its sources is a much better way to go about it. Personally, I would change the ebuild to do this for all sources. We could store our pre-patched sources on our mirrors individually, rather than packaging them up into the genkernel tarball. This way, it is easier to add/remove features via USE flags and other such things without having to roll a new genkernel tarball each time.
I'd be ecstatic with the ebuild-fetches-the-sources solution (see comment #2 ;).
3.1.1b and 3.1.5 both do this; closing bug as fixed.
