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 <[EMAIL PROTECTED]> pgp f-p: A4D3 5BD7 3EC5 7CA2 924E D21D 126B B8E0 <[EMAIL PROTECTED],tug}.org>