[gentoo-dev] Re: Re: Tightly-coupled core distro

["Steven J. Long" <slong@rathaus.eclipse.co.uk>]

On Mon, Nov 19, 2012 at 11:52:46AM -0500, Rich Freeman wrote:
> On Mon, Nov 19, 2012 at 11:32 AM, Alec Warner <antarus@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 ;-)