Le Tue, Dec 15, 1998 at 05:17:50PM +0100, [EMAIL PROTECTED] é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/