Re: busybox features required for Kickstart support
On Friday 15 May 2009, Colin Watson wrote:
> This information was in the citations I provided in my original e-mail.
> At the time I made the original requests, getopt was 1KB and NFS
> mounting was 3KB; Bastian's most recent mail suggests that the latter
> is more than that nowadays.
I didn't check that, sorry.
> I can live without NFS mounting, although I'm a bit frustrated that
> some architectures are held back for the benefit of others (I do
> understand that embedded architectures have more stringent
> requirements).
I'm not propagating holding anything back. I'm just getting a rather
frustrated with the current way decisions about changes are being made
where size impact doesn't even seem to be a consideration anymore. The
only thing I see on the list is "Oh, yes! Sounds nice! Let's do it."
Nobody even bothers to ask the critical questions anymore.
In the past huge efforts have been made by Joey, me, Sylvain Ferriol,
yourself and others to limit the size of D-I. This is very much visible
in the build system, lowmem, kernel-wedge and elsewhere. Now that we're
not building floppies anymore the daily pressure on size is gone a bit,
but the current mentality of not even considering it properly is really a
sign of decay.
If size is no longer an issue, then please let's simplify things and do
away with complications like mklibs. But the reality is that at one point
I had to add a language filter for arm because initrd size was getting
too big for some systems.
In the past we have a few times held back adding new things until we'd
found a way to first gain space somewhere else.
> How about we consider (carefully!) enabling certain features on a
> per-architecture basis?
I'd have no problems with that. IMO that's exactly the kind of design that
should and needs to be done.
> I doubt Kickstart is of huge interest on the more embedded architectures
> anyway; people aren't going to be doing much migration of automated
> deployment configurations from Red Hat on those ...
Right. And the same goes for doing installs from live CD. Hell, most of
these devices don't even boot from CD.
Reply to: