Re: 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

Minimal Install Option

[William Hooper]

Jef Spaleta said:
[major snip]
>  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. 
[ditto]

At some point making your on installer makes sense.  For example, the RULE
project (http://www.rule-project.org/en/) decided that Anaconda was too
resource hungry, so they made their own installer, making a smaller
"minimal" install in the process.

I think the Red Hat Linux "Project" should encourage more of these type of
things.  Heck, I would even go for the stance of removing the "minimal"
install and pointing people to RULE instead.
-- 
William Hooper

Minimal Install Option

[James Olin Oden]

On Thu, 21 Aug 2003, William Hooper wrote:

>  
>  Jef Spaleta said:
>  [major snip]
>  > 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.
>  [ditto]
>  
>  At some point making your on installer makes sense.  For example, the RULE
>  project (http://www.rule-project.org/en/) decided that Anaconda was too
>  resource hungry, so they made their own installer, making a smaller
>  "minimal" install in the process.
>  
>  I think the Red Hat Linux "Project" should encourage more of these type of
>  things.  Heck, I would even go for the stance of removing the "minimal"
>  install and pointing people to RULE instead. 
Except that you can achieve quite
handily a minimal install cd 
using anaconda.  I do it every day.  What really needs to happen
is for someone to come up with some robust general purpose tools
for building distributions based around anaconda.  I have built such
tools but unfortunately they are not open source.  I would certainly be
willing to help with any such project, though.

Cheers...james
>

Minimal Install Option

[Bill Rugolsky Jr.]

On Thu, Aug 21, 2003 at 03:36:08PM -0400, Jef Spaleta wrote:
>  Saves space....i would say that at this point for the
> "intended"
>  audience for rhl...saving space is not a priority. Diskspace is cheap. 
Agreed.  I tend do "Everything" installs, even on laptops. :-)

[Though php-manual (or anything else north of 100MB!) doesn't belong in /var.
 If it isn't already fixed or in bugzilla, I should put it there ...]

I'm more concerned with manageability.  But I have little concern that
as rhl becomes community centered, alternatives to the official install
procedure will mature.


>  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. 
Not from me ...

cf. why-can't-the-damn-developers-learn-to-use-soname.major.minor discussion. ;-)

>  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.. 
Red Hat ends up doing it anyway with foo-$version and foo$oldmajor-$oldversion.
Look at GTK+, Qt, gcc, openssl, ...

>  -jef"if only rpm-analyzer worked not only with hdlists but with
>  installed rpmdb's...gui reverse dependancy trees are neat"spaleta 
Yes, if dependencies are done right, one can prune pretty easily.
Still there are complications due to multiple virtual provides, like
"webclient" and "smtpdaemon".  And install/uninstall scripts can
change
things.  Adding is *always* easier than changing or deleting.

Regards,

	Bill Rugolsky

Minimal Install Option

[Bill Anderson]

On Thu, 2003-08-21 at 15:50, Bill Rugolsky Jr. wrote:
>  On Thu, Aug 21, 2003 at 03:36:08PM -0400, Jef Spaleta wrote:
>  > Saves space....i would say that at this point for the "intended"
>  > audience for rhl...saving space is not a priority. Diskspace is cheap.
>  
>  Agreed.  I tend do "Everything" installs, even on laptops. :-) 
But even that option does not install *everything* last I tried it
anyway. ;^)

-- 
Bill Anderson
RHCE #807302597505773
bill(a)noreboots.com