Re: quick install method (was Re: Deity project schedule problems)

[Craig Sanders <cas@taz.net.au>]

On Sun, 21 Sep 1997, Richard Braakman wrote:

> I think this is too much detail.  (See below)
> 
> > these selection sets should be compatible and cumulative. i.e.
> > you can pick "internet client" + "internet server" + "X windows
> > workstation".
>
> I think this makes it harder, without corresponding benefit.

i disagree. i think that it's not very hard at all (either to code or
for the user to choose) and there is a lot of corresponding benefit.

> (Remember that all combinations would have to be tested).

the only thing to worry about here is package conflicts - will all the
selected packages install together without conflict?

i doubt if there will be many (if any) conflicts between different
"sets". conflicts will almost always be found only *within* a grouping
of similar software (e.g. you'd be hard pressed to find a game which
conflicted with basic internet client stuff).

conflicts can also be fairly easily checked by comparing the packages
in each set against each other. if there's a conflict then one or the
other package must go or an alternative found....with priority given to
more important packages (e.g. networking utils are more important than
games).

dependancies should be satisfied within the set itself, so they won't be
a problem. the obvious exception is that an "X development" set would
require the "C/C++ development" set.

> I think a simple "minimal", "average", or "complete" choice would
> be better.  And we already have something like that in the package
> organisation.  Some (edited) quotes from the policy manual:
> 
>      `important'
>           Important programs, including those which one would expect to
>           find on any Unix-like system. The `important' packages are just
>           a bare minimum of commonly-expected and necessary tools. 
> 
>      `standard'
>           These packages provide a reasonably small but not too limited
>           character-mode system. This is what will install by default if
>           the user doesn't select anything else.
> 
>      `optional'
>           This is all the software that you might reasonably want
>           to install if you didn't know what it was or don't have
>           specialised requirements.

my feeling is that:

a) the user will say "WTF! i have no idea what 'important' or 'standard'
or 'optional' means". e.g is elm 'standard'? or is it 'optional'? what
about gcc? is that 'important' or not? what is "reasonable to expect"?

in other words, i think it's too simple....it jumps from a situation
of having far too much information to make a choice, to having far too
little.

b) you wont get developers to agree on what's 'standard' and 'optional'
either. some will say mutt should be standard, others will say mutt is
dogs' droppings and elm is the standard mailer. ditto for vi vs emacs
(only about 100 times hotter flames), sendmail vs smail, "dev tools are
'standard'" vs "no they're not!".


that's why i think that there should be around 5 (perhaps as many as
10 or so) sets grouped roughly by function...network clients, network
servers, X, development stuff, games, etc. it would be neat, as i
mentioned in my first message, if those sets could be cumulatively
added together. btw, i just looked again at the output of 'dpkg
--get-selections', i think it will be easier to do that than i initially
thought. shouldn't be much harder than 'cat set1 set2 set3 | sort -u |
dpkg --set-selections'

there should be a very small number of user preference questions (smail
or sendmail, which X server, which window manager). at most another 10
questions total...if anyone wants a more customised setup than that,
they can choose the dselect option. only very important or controversial
questions should be asked here....if it's at all possible to avoid
asking a question by making the decision for the user then it will be
nearly always best to do so. the user can, after all, override the
decision by running dselect.


another advantage of having the selection sets be cumulative is that big
packages like emacs or tex can be made into a selection set of their
own. kills the vi vs emacs arguments right from the start: vi (and joe
and ae) are "standard" and to compensate for that insult, emacs gets the
glory of its very own menu entry :-)



> Currently `standard' is the group that can be selected automatically,
> and I think it's what I would call "minimal".  If you add in everything
> from `optional' you get what I would call "complete".  I think that what's

trouble is that YOUR "complete" is probably completely different from MY
"complete".



> > 2nd Rule of Thumb: selection sets to be minimalist. only the bare
> > minimum needed to fulfil the promise of the description to be included.
> > "bare minimum" is defined by the person who actually puts in the work to
> > create and test a selection set.
> 
> I don't think this is a good idea.  The smallest set should be minimal
> (because that's its main point), but hard disk space tends to be cheaper
> than the installer's time.
> 
> The default sets should be listed together with their approximate 
> installed size in megabytes, so that the installer will have some
> idea whether tuning them by hand is necessary.

small is good.  not everyone has a 2gb drive dedicated to linux.  many
newbies are just trying it out for the first time on a smallish partition.

people who want more than the 'bare minimum' can always use dpkg or dselect
to install extra stuff.



> (Perhaps "tuning" is a better name than "expert option".  We don't
> want to scare people away from dselect, we just want to offer an
> alternative.)

good point.


> P.S. Why are we discussing this on debian-private?

because my suggestion was in reply to bruce's message about deity
delays. stuff on debian-private shouldn't be cross-posted to other
lists.  

BTW, i have no problem at all with this discussion being moved over to
debian-devel where it probably belongs.

craig


--
craig sanders
networking consultant                  Available for casual or contract
temporary autonomous zone              system administration tasks.


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-private-request@lists.debian.org . 
Trouble?  e-mail to templin@bucknell.edu .