Re: dpkg modification: non-interactivity
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 <Kristoffer.Rose@ENS-Lyon.FR>
pgp f-p: A4D3 5BD7 3EC5 7CA2 924E D21D 126B B8E0 <krisrose@{debian,tug}.org>
Reply to: