Minimal Install Option

[Bill Rugolsky Jr.]

On Thu, Aug 21, 2003 at 09:38:09AM -0400, Jef Spaleta wrote:
> File it as a bug! Or maybe you want to step up and be part of a
> worthwhile discussion as to re-working of the existing minimal install
> option. Since it seems its really a more a matter of how the packages
> are grouped and which groups a minimal install actually installs..its
> more a policy issue than an expert coding issue. This seems like
> something we can have a nice lovely little community discussion
> about...instead of just poking repeatedly at the anaconda maintainer to
> remove this one package here...or this one other package..or maybe add
> this one package to minimal. And its certainly a better idea to fix the
> current minimal install offering than adding another minimal minimal
> layer beyond the "broken" minimal. 
> 
> http://www.redhat.com/archives/rhl-beta-list/2003-July/msg00569.html

This discussion always tends to conflate different notions of "minimal".

The question is "minimal" w.r.t what criterion?  Is it the bare list
of packages necessary to get to a login prompt on a standalone machine?
Is it a networked host?  Is documentation included?  Manpages?
Info files? /usr/share/doc?

I'd like to see a "bootstrap configuration" that installs enough that
I can install more using up2date or yum.  That generally means "basic
networking (and firewalling)" + any specifics needed to get my host
connected to my network or ISP (i.e., ppp, dhcp, etc.).

Beyond that, agreement tends to dissolve, because intended uses vary widely.
This is where the Gentoo model does a good job of factoring the requirements, 
because I may want to install a bunch of packages, keep the manpages and
info files, but eliminate /usr/share/doc, and shun X/KDE/GNOME.

Doing this in a binary distribution means much finer packaging.  Red Hat Linux
has historically packed a lot into a few packages (e.g., Perl), whereas
other RPM-based distros break it all out into individual sub-packages
(hundreds of them!).  Separating packages into executables and libraries
is a good idea not only because it allows multiple libfoo* installs, but also
because it saves space when all that one wants are the libs, and not
the default front-end application, which may have additional dependencies.

[And then there is kernel-utils -- lots of unrelated binaries, all of which
are quickly out of date, and complicate the installation of superior tools
like smartmontools.  One should try mightily to decouple code that
is hardware-dependent, since things like x86info and smartctl change with
each release of a new processor or SCSI/ATA/SMART revision.]

Regards,

	Bill Rugolsky