Re: AutoRPM
Raul Miller <rdm@test.legislate.com> writes:
> Steve Dunham <dunham@cps.msu.edu> wrote:
> > That's hard to do with dpkg, since many of our postinstall scripts are
> > interactive.
> It's probably time that we formalized the interface between dpkg scripts
> and installer, to enable things like:
> (1) automated installs
> (2) asking questions ahead of time
> (3) gui interfaces
> (4) etc.
> Perhaps linux kernel configuration could be used as an initial model.
I've tried to categorize what package post-install scripts do, I think
it can be broken down into:
1. Variable setting (boolean and string-valued settings)
2. Scripts that take the values and configure the package
3. Batch operations (glimpse/man indexing, menu creation)
4. Custom interactive programs. (X configuration, maybe MIME
configuration).
IMHO, we should address these by:
1. Introducing a new configuration file for the variables, with
descriptions, and maybe layout information for a gui. (Something
that can be used to display both gtk and newt guis.)
2. Restrict the post/pre scripts to be non-interactive
3. Add a mechanism to schedule a batch operations to be done after the
set of packages is installed.
4. Add a mechanism to keep track of pending custom interactive
programs (so the installer can run them afterwards, or for a
completely non-interactive install, the sysadmin can deal with
them later). These should be rare.
The variables should be layed out in a tree format, e.g.
package.varname, with some pseudopackages so that common information
can be shared between packages.
A site wide installation system could then have a global file, and a
per machine/netgroup file that overrides some of the values in the
global file. (This is just for package installation time
configuration.)
A good installation program can then scan the packages for needed
variables, and ask the questions all at once instead of spreading them
throughout the configuration process. A non-interactive install can
keep all the values in a file.
At the very least this would allow deity to have a more graphical
configuration process.
The key ideas for developing a solution to the installation problems
are:
Allow for graphical interaction, text-mode interaction, and file
driven interaction.
Ask all questions at once, try to keep from asking same question
twice.
But tie the variable list and associated information with the
packages themselves.
Question: Is anybody looking into this? Are the Deity people
planning on addressing this - or the debian-admin list?
Steve
dunham@cps.msu.edu
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to:
- Follow-Ups:
- Re: AutoRPM
- From: Raul Miller <rdm@test.legislate.com>
- Re: AutoRPM
- From: Roman Hodek <Roman.Hodek@informatik.uni-erlangen.de>
- Re: AutoRPM
- From: Christian Leutloff <leutloff@sundancer.oche.de>
- Re: AutoRPM
- From: Behan Webster <behanw@verisim.com>
- References:
- AutoRPM
- From: Rainer Dorsch <rainer@rainer.informatik.uni-stuttgart.de>
- Re: AutoRPM
- From: Steve Dunham <dunham@cps.msu.edu>
- Re: AutoRPM
- From: Raul Miller <rdm@test.legislate.com>