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: