Re: dpkg modification: non-interactivity
Le Tue, Dec 15, 1998 at 05:17:50PM +0100, Kristoffer.Rose@ENS-Lyon.FR écrivait:
> Mitch writes:
I would like to make a preliminary remark. Did you guys read the different
versions of the "Configuration management" texts posted to -policy during
last months ? Because i've read them and it would be better that we all
know well what we're speaking about and what has already been proposed, etc.
Please take a look at least at these following messages :
- Wichert's last proposition :
http://www.debian.org/Lists-Archives/debian-policy-9808/msg00004.html
- An interesting message from Ian Jackson :
http://www.debian.org/Lists-Archives/debian-policy-9808/msg00299.html
- The last thread about it (started by myself) :
http://www.debian.org/Lists-Archives/debian-policy-9811/msg00091.html
- Possibly this one too, but nobody repplied to it :
http://www.debian.org/Lists-Archives/debian-policy-9811/msg00099.html
Good reading. :-)
> 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 :).
I think, we should try to limit the modifications that have to be made to
dpkg. It's the best way to be sure of the backward compatibility.
Howewer, dpkg will probably need to be modified.
> 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.
How do you call the state between non-interactive configuration and
interactive configuration ? Is the packahe configured . half-configured ?
I speak here of dpkg understanding of a package state.
The problem is that this difference between non-interactive configuration
and interactive configuration has no sense. For one package, it will be
configured after the non-interactive one, for the other it will be after
the interactive one.
I think there's no need to have two postint, but I have already suggested
that we should have a "preconfigure" script that "could" be run in order
to pre-answer the questions that the postinst might ask.
However it doesn't answer the problem of the APT user if he hasn't a
configratiuon database already filled in. But that's not a problem
I think :
- he downloads the packages (long)
- he answers some questions (short)
- he lets the system install itself (long)
The big problem we have currently is that we need to stay with the
machine because the current installation ask all questions during
installation (and not before or after).
> 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!
So things are not better than before.
I don't like this idea of cookie because as you say it's better when it
is versioned-dependant however I do not want to reconfigure the package
for each package upgrade... the configuration database means also :
- you can modify by hand the configuration database about something
precise whereas with the cookie system you should reconfigure the whole
package.
- you cannot easily grep/sed the cookies whereas the database is
designed to be modified by the administrators.
cookies also implies the modification of dpkg in order to
create/read cookies. A real database however could be easily read by
the postinst script itself using a special utility.
Cheers,
--
Hertzog Raphaël ¤ 0C4CABF1 ¤ http://www.mygale.org/~hra/
Reply to: