The mkinitrd and lvm2 packages depend on insmod.static, which is built when module-init-tools is ./configured using defaults. (LVM2's dependency comes from the lvm2create_initrd script - both mkinitrd and lvm2create_initrd are designed to be able to create an LVM+RAID compatible initramfs. While this functionality is also available in genkernel, the QA issue still exists with these two packages... However, the module-init-tools-3.11.1 ebuild specifies --disable-static-utils, which causes insmod.static not to be built. The solution is of course to remove this configure option, or move it into a 'static' use flag. Removing this configure option from the ebuild manually has had no negative impact on its ability to build, on amd64 with the ~amd64 keyword. Reproducible: Always Steps to Reproduce:
we're not going to force useless cruft on people who arent using the right tools i can add USE=static that creates static binaries (that's trivial), but i'm still not inclined to add symlinks. better to fix mkinitrd/lvm2 to fall back to the normal tools if the .static wasnt found.
Removing --disable-static-utils seems to build both a static and a dynamically linked version of insmod - seems somewhat more elegant than symlinks I agree, and using a USE=static flag would make the additional insmod.static binary optional
i know what --disable-static-utils does seeing as how i'm the one who wrote the switch. i'm not going to force static binaries onto the majority of people who dont care, and the normal USE=static behavior is that the normal binaries are static. not that additional static copies are created.
Hmm. How about installing insmod.static in place of the insmod binary and not symlinking, in the case of the USE="static" flag? Modifying mkinitrd and lvm2create_initrd would be made even more trivial with that change
how about we add a new USE flag for generating the static bins in addition?
ive committed my USE=static: http://sources.gentoo.org/sys-apps/module-init-tools/module-init-tools-3.11.1.ebuild?r1=1.1&r2=1.2 i dont see any value in supporting ".static" suffixes. fix the mkinitrd/lvm2 packages to fall back to the standard binary if the ".static" isnt found.
Thanks!
I think that forcing static binaries to overwrite dynamic ones is one of the worst possible choices here. Possible options: 1. only dynamic. 2. only one of static OR dynamic, controlled by USE=static. 3. BOTH static and dynamic binaries, possibly controlled by a new USE flag. On each of these: #1: mkinitrd/lvm2 should pull in libs. LVM2 will be able to do this shortly, there's already a submission, but I asked the user to take it upstream first (bug 299656). #2: If you wanted static binaries for one purpose but the dynamic ones for normal system usage, you're S.O.L. #3: Just costs a little extra diskspace, and is less messy than making a special case of building the statics yourself and copying them around. Anybody building a rescue env from their system (rather than building seperately) just needs to copy the .static binaries.
USE=static behavior in module-init-tools (i.e. your "2") is exactly how USE=static was designed and how it's used throughout the tree. adding a new random flag to arbitrarily install both dynamic and static copies of programs is a bad idea (ignoring the ".static" convention that module-init-tools has historically used). it's non-standard in Gentoo and largely useless. your argument about wanting static binaries for a specific purpose doesnt make much sense. if that's what you want, we have ROOT. and we have `emerge -B`. there are plenty of generic methods for tackling this issue. do mkinitrd/lvm2 already fall back to the non ".static" suffixed filenames ? if so, then the issue here is fixed in my mind. the library search/lookup is for another bug and upstream as you mentioned wrt lvm2.
(In reply to comment #9) > USE=static behavior in module-init-tools (i.e. your "2") is exactly how > USE=static was designed and how it's used throughout the tree. > > adding a new random flag to arbitrarily install both dynamic and static copies > of programs is a bad idea (ignoring the ".static" convention that > module-init-tools has historically used). it's non-standard in Gentoo and > largely useless. The .static convention is larger than just module-init-tools, it's around in a lot of other critical-path system apps for booting. I was originally just going to do it completely non-conditional. > your argument about wanting static binaries for a specific purpose doesnt make > much sense. if that's what you want, we have ROOT. and we have `emerge -B`. > there are plenty of generic methods for tackling this issue. Only that this means every tool to make initrds (mkinitrd, lvm2create_initrd for this purposes of this bug) needs to be modified, or the user needs to do the -B and copy the .static files manually, and then they potentially get out of date. > do mkinitrd/lvm2 already fall back to the non ".static" suffixed filenames ? > if so, then the issue here is fixed in my mind. the library search/lookup is > for another bug and upstream as you mentioned wrt lvm2. Yes, they do, but if those aren't static, then they fail when you try booting from the created env, because libs aren't there.
i'd say current USE=static handling by lvm2 is wrong. if you want to add an additional USE flag to allow installing of both, then go for it, but dont break existing conventions. as for maintaining a separate tree of binaries, that's an advantage imo. you can easily manage custom build flags (-Os) and USE settings on them. as for m-i-t, i'm not interested in a dual USE flag for ".static" suffixes, so this bug is fixed now.
