[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: SEUL: seul-dev-install




>  4. seul-extensions in the installer.
>     the concept here is that the installer will support a higher-level
>     packaging scheme than what is currently in use.
>     the installer should provide a framework for selecting things like
>     "typical", "full", "minimum", and "custom", installs, and each should
>     be in the context of a particular type of user.
>     redhat already implements some stuff to support configuring sets of
>     packages to be used in an installation.  this needs to be enhanced,
>     though, to allow easy configuration of user/install-style, and to pass
>     through info on package-sets to the seul database developed by the
>     admin group.  ignore that last part for now, but be ready for it when
>     the spec is done.

I'll expand a little from what my understanding of it is from the discussions 
we had on this topic:


There are a number of different targets for SEUL.  We need to address them in 
a highly configurable way.  Examples:

1) the typical "put the CD in with a magazine" install, as well as 
off-the-shelf at Computer City or Frys:

    This install can assume that the user isn't going to be doing anything to 
extensive, basically using the simpler 'productivity' apps and the Internet.  
It should install things like nifty applets (cd player, calc, scheduler, 
etc.) and the appropriate applications.

2) a semi-custom distrib, for instance one for marine biologists (i.e. Aldo):

    This installs fewer nifty applets, more useful applications, including 
scientific ones.

3) a very custom distrib, for use in a corporate environment where you have
>100 systems that need to be installed the same way:

    This can install whatever the corp needs, including productivity stuff, 
networking apps, collab stuff, etc.


This is how this could work: the installer works from a configuration file.  
This file acts somewhat like an RPM control file, in that it defines things 
like who wrote the config, what it's called, etc.

The config file would also detail what packages are installed.  #3 above 
would have a fixed set of packages to install, whereas #1 and #2 would have 
options.  These options would then have to be parsed by the installer and fed 
to the user.  But in the case of #1, we want to provide the user with the 
'typical', 'everything', 'minimum', and 'custom' options, though in reality, 
each of those will be a different config file.

Basically, #1's menu looks like:

A) Typical install - Word processor, E-mail, UseNet, and WWW browser
B) Minimum install - Only enough to get running, you install stuff later
C) Maximum install - Install *everything*
D) Custom - Select what you want to install

And then you have something like #2, which then adds the following:

E) Marine biology typical install - WP, SS, DB, graphing, E-mail, WWW

etc...

In the case of D) the installer would then go and query the user as to what 
they want installed.  I won't go into that part except to say: Be Verbose!  
Tell the user what it is their installing, unlike RedHat.  Slackware does a 
pretty good job of it, but as they don't really have a package manager per 
se, that's out of the question.  Besides, rpm and dpkg both have Description 
fields...

Oh, the idea behind #3 is that a IS person would load up a utility we'd write 
that would create the config file (based on the same menus you get for a 
'custom' install?), then effectively 'burn' a floppy that has the right 
config information on it, as well as just the right drivers for his group of 
10,000 computers that he has to install over the network.  He then puts his 
custom boot/install floppy in the drive, turns on the computer, and it's 
installed automatically.


This is all a little hazy, so anyone interested in the installer/distrib 
stuff, start commenting...

TTYAL,
     Omega

        Erik Walthinsen - Programmer, webmaster, 3D artist, etc.   __
  __                                                              / /\
 /  \           omega@sequent.com         Work: (503)578-5314    / /  \
|    | M E G A  omega@aracnet.com         Home: (503)281-4281   / / /\ \
_\  /_          psu12113@odin.cc.pdx.edu  Majoring in CS       / / /\ \ \
                                                              / /_/__\ \ \
Omega Station: http://www.aracnet.com/~omega/                /________\ \ \
     Info on Linux, Graphics, Descent, Laptops, etc.         \___________\/


----------------------------------------------------------------------------
Simple End User Linux Mailing list
To be removed from this mailing list send a message to majordomo@txcc.net
with the line
unsubscribe seul-project
in the body of the letter.
----------------------------------------------------------------------------