Minimal Install Option

[Jef Spaleta]

Bill Rugolsky Jr. wrote:
>Beyond that, agreement tends to dissolve, because intended uses vary
>widely.

That was sort of my point...about having a consensus view not being
ignored. Good luck finding that consensus. Maybe a 460Meg "minimal"
doesn't work for everyone...but if it works for 80% of the userbase or
for the intended audience or for an intended use...then maybe that
460Meg minimal install is the best fit for the development resources on
hand...and we need to move on.

And there is a logic fault involved with any argument that says you can
assuredly create any sort of install process meeting the competing
interests of easy maintainability from the development side, easy of
use/simplification for the non-technical audience...and easy of
use/customization for the technically proficient user. I humbly submit
there are trade-offs invovled and there is no perfect solution. And in
the final analysis...the technically savvy users have tools already to
do customized installs...kickstart just makes more sense for a lot of
situations where technically proficient users want the option of being
lazy, instead of pipedreaming about an installer that meets their
specific usage interests. And if kickstart doesn't do it for you and you
are in the 0.1% of people who know they need a very exactly specific
install where you can't go back in with a post install script and
uninstall things you don't need because you have exactly 200Megs of
harddrive space you can use for the install...well rolling your own isos
is probably best...anaconda-runtime also exists for a reason. There is
an intended audience for rhl....and i would again humbly suggest that
putting in a lot of easy to find options in the default iso images meant
for the 0.1% of the userbase outside of the intended audience who should
be using kickstart or anaconda-runtime to make extremely customized
installs...is going to lead to problems with the intended userbase and
waste developer time which could be spent streamlining the installer and
debugging the installer for the intended install situations. The people
who KNOW they need to squeeze a Red Hat install into 100 Megs of
harddrive space, are going to need to know far more about other avenues
of streamlining and customization to get things to work just like they
want them to. 30Megs just for the default kernel modules
alone....yippie!!!!!...at some point you build a customized iso to get
exactly what you want.   

The way forward for everybody, is to work out how to create a 2 stage
install that moves a lot of the package selection crap out of
anaconda...and into a firstboot situation...a firstboot situation where
you get access to the actually system resources...and not those
resources available in the installer ramdisk image. So what if
anaconda's "minimal install" includes a set of packages that you end up
not wanting to install. Harddrive space is CHEAP. We need to find one
and only one distro provided "balanced" minimal install sequence that
provides enough tools so that you can come back in after a firstboot and
do a wealth of customization..including package removal...via
repositories...via a well baked r-c-packages..via personalized
scripts..etc....outside of the limited ramdisk anaconda gets access to.

If being able to remove packages post 1st stage install is the sticking
point...that needs to be worked on. Clean package removal is important
in a number of situations...even for the intended non technically savant
audience. Figure out how to do that cleanly...and you help
everyone...not just the 0.1% of people who need to do a 73Meg harddrive
firewall install. Once we recognize the package removal is a hard
problem...that doesn't mean we should work around that problem with
craptastic kludges that complicated the installer process. We need to
tackle the hard problem of how to do package removals well...and
streamline the 1st stage installer....that is a better use of the
limited developer time....its the biggest long term bang for the
buck/doughnut/beer/pizza/long winded patriotic essays/whatever you use
to bribe developers with to do yer bidding.

If you need to worry about having only 200Megs of Harddrive space or
only 4 megs of memory at this point in the game...you really should be
rolling yer own media sets or something other than expecting the default
rhl image to cater to systems limitations for which predate
cobol....anaconda-runtime exists for a reason.

>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.

Saves space....i would say that at this point for the "intended"
audience for rhl...saving space is not a priority. Diskspace is cheap.
But I'm sensing a very technical and very drawn out debate about what
the pro's and con's to very fined grained packaging is. And the only
people really qualified to wade into this one...are people who should be
busy fixing high priority bugreports...instead of posting to this thread
or sending email to me or you offlist. But I imagine taking a good hard
look at what it would mean to allow multiple libfoo* installs would be
another very enlightening discussion of the trade-offs among the
interests of difference segments of the userbase..

-jef"if only rpm-analyzer worked not only with hdlists but with
installed rpmdb's...gui reverse dependancy trees are neat"spaleta
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-test-list/attachments/20030821/4f7398ae/attachment.sig>