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

Re: dpkg modification: non-interactivity



Mitch writes:
> This confuses me.  And I think others may also be getting confused because
> we have suggestions coming from two different use cases.

Indeed: I was trying to address both even if it wasn't very clear :)

Here is the essence of my PROPOSAL again:

  a. Policy is changed to FORBID INTERACTION during postinst.
  b. Policy adds a SECOND SCRIPT PHASE -- call it postinst-interactive --
     where one *is* permitted to do interaction.
  c. Policy requires that postinst-interactive leaves a COOKIE behind that
     makes subsequent runs of it non-interactive for the same version. 

I assume that this is implemented in dpkg (hey, I might even help because
these are *really* easy :).

> Is there a good way to reconcile the needs of these two types of users?

I think this addresses both issues even if it was primarily targeted at the
first.

> 1) The downloader -
>    This is the user who gets his/her updates over the Net and just wants
>    to be able to run apt-get, then go to a movie, and come back with
>    everything done, except for the few configuration questions that
>    need answering.  For this user, having the configuration done before
>    installation doesn't make sense because the package won't be there
>    until after the download, which would split the upgrade into two cycles.
>    DOWNLOAD <wait1> CONFIGURE <wait2>
>    instead of the better
>    DOWNLOAD <wait1> <wait2> CONFIGURE
> 
>    * Note that <wait1> is the time spent waiting on the download, while
>      <wait2> is the time spent unpacking and installing the files.

IMO this should be addressed by Policy imposing that postinst does not do
any interaction: this is the vast majority of the cases, fortunately!  That
makes <wait2> uninterrupted.  The second script phase -- call it
postinst-interactive -- isolates the <configuration> phase.

This is a good way because it provides an EASY MIGRATION PATH: once policy
is changed we just start filing bugs agains postinst scripts that *still*
do interaction.  This is EASY because there is an EASY FIX (even if it may
not be the best): one simply renames postinst to postinst-interactive!

It is true that this will not completely eliminate configuration-dependent
waits but this is payed back by the smoothness of the transition, IMHO.

> 2) The multi-machine admin -
>    This user wants to install and config on one machine, then push
>    everything out to multiple machines.  He/She needs to be able to
>    pre-configure everything going out to those machines.
>    The problem I see here is that the multi-machine admin will want
>    to do more than answer the required administration questions...
>    custom conffiles with options probably not covered by the standard
>    postinst questions.
>    That way instead of
>                        / -- <wait2> CONFIGURE
>    DOWNLOAD <wait1> --|---- <wait2> CONFIGURE
>                        \ -- <wait2> CONFIGURE
> 
>    You have the much better:
> 
>                                  / -- <wait2>
>    DOWNLOAD <wait1> CONFIGURE --|---- <wait2>
>                                  \ -- <wait2>
> 
>    which avoids the multiple CONFIGURE stages on the individual machines.

My proposal addresses this in a slightly different way ...

> For the second case, would it be best just to provide more/better tools
> that allow the admin to change the conffiles and/or installscripts within
> a .deb without having to get mired down in packaging details?

... because I think this is right.  I propose to recommend a "master-slave" 
approach where multi-installation is done in two steps:

First the master machine is updated normally, just as for a single-machine installation:

  SELECT what to do on master machine (dselect point 2+3)
  <wait1> for primary download
  <wait2> for postinst
  CONFIGURE master machine during postinst-interactive

This leaves the cookie files on the master machine so each slave is then
installed with

  MIRROR package selection to slave
  MIRROR master cookies to slave
  <wait1> for secondary download
  <wait2> for postinst
  <wait3> for postinst-interactive based on cookie

For this to work we need to support...

  a. Mirror a package selection.
  b. Mirror the cookies.
  c. Help package maintainers make postinst-interactive cookies.

The first two are IMO best done with the debian package system: just let
the installation on the master *create* a .deb that

  - depends on all the packages (with version!) selected on master.
  - preinstalls the cookies files.

For the last point ... well, that needs to be discussed.  I believe it is
very important that this is made as easy as possible which is why I prefer
that the cookies are version-unique: that way mistakes do not break things
in any serious way and can *always* be fixed with a new version.

I believe this is the best solution since it does not depend on a network
connection: only the essentials are packed and can even be put on a
diskette and passed around (since the "shared" part -- the actual debian
packages -- are known to work).

Two minor but important remarks: First the use of package caching can
mostly elininate the "<wait1> for secondary download".  Second, if a
package does not yet support a cookie then the worst that can happen is
that "<wait3> for postinst-interactive based on cookie" degenerates to
actually ask a few questions -- a bug but not a serious one.

Cheers,
	Kristoffer
-- 
Kristoffer Høgsbro Rose, phd, prof.associé  <http://www.ens-lyon.fr/~krisrose>
addr. LIP, Ecole Normale Supérieure de Lyon, 46 Allée d'Italie, F-69364 Lyon 7
phone +33(0)4 7272 8642, fax +33(0)4 7272 8080   <Kristoffer.Rose@ENS-Lyon.FR>
pgp f-p: A4D3 5BD7 3EC5 7CA2 924E D21D 126B B8E0   <krisrose@{debian,tug}.org>


Reply to: