On Mon, Nov 19, 2012 at 11:52:46AM -0500, Rich Freeman wrote: > On Mon, Nov 19, 2012 at 11:32 AM, Alec Warner <anta...@gentoo.org> wrote: > > > > Debian / Ubuntu have a tool that basically does this. Its > > update-initramfs. I believe it is called from..the postinst of > > packages that are supposed to be in the initramfs? honestly I'd have > > to look up how they implemented it. > > Not a bad idea, with a corresponding eselect tool to control what kind > of initramfs you have (dracut, genkernel, none, > remind-me-but-I-roll-my-own, etc). The ebuild would just call the > function, and the function would handle it accordingly. > The issue there is "packages that are supposed to be in the initramfs," since we've been told the initramfs is a custom thing for our situation. (Which is kinda my issue with just dumping the whole problem on end-users and admins who are not using a prepackaged distro without customisation, instead of maintaining backward-compatibility.)
Mind, I don't have an issue with developers deciding certain packages are critical: after all the same knowledge informs what should be on root. I just don't think that the above answers the problem comprehensively (and thus it isn't worth the maintenance headache, if it can be avoided.) All the tutorials, and packages, I've seen on the forums take you through deciding exactly what you need in the initramfs. So given that each user has a potentially different set of stuff on there, the robust method would appear to require the mangler to know which packages had files on there, and to update them accordingly (or run the generation tool, or warn, as you said) when one of that set were updated. Simply triggering a warning when one of a named set is built, sounds like a start. (The initramfs generation script could run qfile to build/check the set.) Thereafter it's "just" a matter of hooking into that, if the functionality is not already present. (I don't run unstable portage any more, as I need to be close to what end-users of our emerge wrapper are using, so I'm not up on the current state of 2.2. I'd prefer not to have to script round this issue, since it doesn't affect me at all.) Regards, SteveL. -- #friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
