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

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: