Re: Creation of typical installations...
On Wed, 24 Sep 1997, Sam Ockman wrote:
> I'd like to create a system where upon installation the user will be
> presented with the option of, immediately after installing the base option,
> of installing three typical Debian installations...
>
> Large
> Medium
> Small
>
> (okay, so the names need some work...)
this is very similar to a proposal i made a few days ago. it's a good
idea. the only thing wrong, imo, with it is that it goes straight from
the current situation (too much choice) to a situation of not enough
choice.
small, medium, large doesn't really tell a user enough. it's better to
give the user a choice of broad categories of functionality, e.g. "X
workstation", "C/C++ development", "text games", "X games", etc.
> They would be sets of each other. Large would contain medium which would
> contain small. Each would be a collection of standard Debian packages.
> I'd expect the sizes would be...
>
> Large about 550-600 megabytes
> Medium about 300-350 megabytes
> Small about 100-150 megabytes
>
> That way large could fit neatly onto a CD as a live file system. S.u.S.E.
> and Red Hat both have live file systems, and I find them very useful...(of
> course I use Linux differently from most people...)
> I would imagine that if we could implement this most people (80% say) would
> choose this to use this feature rather than dselecting packages...then once
> they are comfortable with their working, feature rich Debian system they can
> start using dselect to pick exactly which packages they want.
yep.
> One thing that this would give the Debian system is more rebliability...my
> recent experience with installing around 1000 packages (approximately every
> package out there that didn't conflict...) is that the packages didn't work
> together as smoothly as I would like, nor as smoothly as when picking for
> example a full installation under Red Hat. We can test the new exact
> combination of packages thoroughly, and this testing will have ripple
> effects through the rest of Debian.
what do you mean by "didn't work together as smoothly as i would like"
- do you mean you had install problems or that they didn't operate as
expected after you installed them?
what went wrong?
> So, technically this is an easy thing to do...except for the interactivity
> of package installation. It seems like there has been an ongoing debate (as
> far as I can tell unresolved) about how/when packages should ask questions
> during installation. Perhaps we could add a command line option to dpkg
> that will signal the package should not ask any questions prior to
> installation but just make best guess judgements. That gives the best of
> both worlds...
imo, that's a completely separate issue, and one that has been debated
at length many times. leave it for another project (deity or whatever).
the focus for this one should be on quickly producing something that
works, without too many bells and whistles....just something which makes
it much quicker to select a whole bunch of packages for the first-time
installer.
think of it as a throwaway script - when something better comes along,
throw it away.
here's what i proposed a few days ago. there have been a few comments on
it since then, and i've reconsidered the idea of having "internet client"
and "internet server" packages. it would be better to have an "internet"
set plus "webserver" and "ftp server" sets. comments and criticisms
and improvements are welcome.
: i have a suggestion to make:
:
: if deity is not going to be ready for the release of 2.0, then we need
: a simple perl/sh script wrapper around 'dpkg --set-selections' so we
: can offer an extremely quick install. maybe it could even use dialog
: for tick-a-box style installation (i hesitate to suggest this because I
: *loathe* dialog - but it IS what is used on the install floppies).
:
: after base installation and reboot, drop the user into a menu offering
: one of a number of pre-tested dselect selection sets (plus an "expert"
: option to run dselect).
:
: the recent thread in here about the iX magazine review highlights why we
: need something like this, and need it NOW.
:
: IMO it doesn't have to be perfect, it doesn't have to have all the bells
: and whistles, it doesn't even have to be "Good"<tm>. it just has to work
: and save people some time...the aim is to cut down the install time
: from 3 or 4 hours (about what the first-time debian user will spend in
: dselect going through 1400+ packages) to half an hour or so.
:
: dselect isn't too hard to learn (IMO), but with so many packages in
: debian now it really is throwing newbies into the deep end before they
: even get started. when i'm teaching people about debian and dselect, i
: find that the hardest thing is for people to get over their awe at just
: how many packages there are to be installed (and by extension how many
: things there are for them to have to know and learn). too much choice
: can make it nearly impossible to choose...especially when you have no
: idea what a package is or why you might want it.
:
: anyway, that's a digression. back to the point...here's some suggested
: sets:
:
: "basic system"
: not much more than base. (may not be useful..might be better
: to have "net client" as the default selection set)
:
: "internet client"
: netbase, netstd, and friends
:
: "internet server"
: wu-ftpd, apache, others.
:
: "X workstation"
: X + basic X clients. svga server or query user for card type.
: IMO it would safe to assume "internet client" as well. offer
: choice of windows managers, or just pick whichever you prefer as
: default (IMO fvwm95 because it'll be more familiar to newbies -
: non newbies can easily pick whatever they prefer)
:
: "Text-only Games"
: including net games stuff like tf mud client and ircii
:
: "X Games"
: again, including networked games stuff
:
: "TeX"
:
: "C/C++ development"
:
: "X development"
:
: "java development" (or maybe not since jdk is non-free)
:
: etc.
:
: these selection sets should be compatible and cumulative. i.e. you can pick
: "internet client" + "internet server" + "X windows workstation".
:
: it may be worthwhile breaking down things like "internet client" into
: "mail client", "basic internet clients" and "other net clients". maybe
: not...the higher the granularity, the more work involved, and the less
: benefit for the user (we already have all the granularity we need with
: .deb packages :-)
ignore this last paragraph. i disagree with it now :-).
:
: IMO it is better to have LESS choices at this stage. after all, this is
: only a quick-install method. anything else can be installed with dselect
: or dpkg later (and that SHOULD be emphasised to the user, that this is
: only a shortcut to make their first-time install faster and easier).
:
:
:
: i estimate that a quick hack solution to do this should take no
: more than a few days. avoid arguments over what goes into each set
: by adopting the first (or the "best" - anyone volunteer to judge?)
: selection set provided by any developer (or user - there's an idea for
: getting some user involvement in debian dev).
:
: i don't think that it needs to be any more than a "quick hack" because it's
: only a stop-gap solution until deity gets here.
:
: Rule of Thumb: only packages in main can be in the selection sets. no
: contrib, no non-free, no non-us.
:
: 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.
:
: 3rd Rule: all selection sets subject to the usual testing team and
: release management procedures which worked so well for us last time.
: (btw, belated congrats to you all - you did a great job)
:
: comments?
:
: 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-devel-request@lists.debian.org .
Trouble? e-mail to templin@bucknell.edu .
Reply to: