Dear Raphael, > 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.
> Good reading. :-) Yes, indeed, they are good reading and I have read these and others before them. And they are all *way* to complicated for my taste and *way* to difficult to enforce as a "standard" any time soon. > 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. Certainly. > How do you call the state between non-interactive configuration and > interactive configuration ? Is the packahe configured . half-configured ? Something like that. > 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. It will only be configured after *both*. In between it will be half-configured. Both scripts are optional (like postinst is now). > 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. This is sometimes not possible. The only thing that is *always* possible is to configure once all packages have been ... half-configured. Hence the "minimal impact" principle (KISS) suggests this. It also conforms well with the desire to have all configuration last as Mitch requested it. > 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) Preconfiguration is difficult. It is error-prone. It requires new code and possibly even hairier things (like Configure-Depends: etc.). And I am strongly against abruptly *requiring* a complex thing in Policy. I am for a simple principle that initially reuses existing packages as they are with merely a renaming of interaction-demanding scripts. KISS: we can have this in potato. > 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). Yep. > So things are not better than before. Oh, they are much better: all interaction-requiring packages are grouped, last. There are not that many of them, even now, it just seems so because the typically 3-4 interruptions you must attend to are spread out over the half-hour a major update takes. Per machine. > 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. Don't get me wrong: I am all for a full configuration-database-whiz-bang. But that should be optional -- say an independent preconfiguration package that individual packages can adhere to and query to "do it all in postinst", i.e., without any attendance. Such a thing would be a great asset for debian, like menu, mime, etc. But I insist that the KISS solution should come *first* to avoid loosing before we get really rolling. > 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. No: cookies are completely private to the package and version. Only the name should be standardised to make mass copying easy. They *only* serve to make reinstallation of the *same* package smooth, to ease multi-host installs. Cross-version configuration stability requires a proper database. Great stuff! Do it! But I want the stable KISS solution for real, now. It is so easy and it solves 95% of the nuisance of installing debian. 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>