Re: Common set of debconf templates
On Thu, Oct 14, 2004 at 03:44:00PM -0400, Joey Hess wrote:
> Brian Sutherland wrote:
> > Am I missing something?
>
> Only that dpkg-preconfigure is not guaranteed to be called,
Thanks for pointing out this, Joey
> and if it is
> called, there is nothing really to ensure that it runs for all debs that
> are being installed (since there is no status updating done to note that
> a package was preconfigured). So if the preconfiguration does not happen
> at all, or fails for some reason on the package containing the shared
> templates, then you could be left with a problem.
>
> dpkg configuration ordering should take care of it for postinst scripts
> (but not for preinsts), if preconfiguration was not done at all.
>
> At a minimum, you'd break this case:
>
> dpkg-preconfigure some.deb
>
> There's no guarantee here that some.deb's dependencies are already
> installed, and so it may miss templates or use versions from an older
> version of the template package than the one it depends on.
While I am not sure about all possible configurations of meta package
managers, I do not think many normal users will do standalone calls to
'dpkg-preconfigure some.deb', only advanced users. Regarding out of the box
apt, if I am not wrong it does all preconfiguration as a whole, first
loading templates if appropriate, and then running .config files. Some
configuration options might make it behave differently, but again this
should be for advanced users only. Single installation by dpkg currently
does no preconfiguration at all, and everything is left to the postinst
stage, although this might change in the future, I hope in a compatible
way.
> You would at
> least need to take care to exit the config script in this case and let
> it re-run when the package is installed,
This could be achieved through
if ( master_question_exists ){
register our question after the master one
do the debconf work *only* for this question or depending questions
} else {
warn "Please do not try to manually pre-configure this package unless
its dependencies are already pre-configured"
}
so in 'dpkg-preconfigure some.deb' nothing (but issuing a message) will
be done unless master question is registered. Of course this is not at all
perfect and might lead to an ancient template text being used (e.g., if a
backported package is installed in a previous release having an ancient
template text for that question) unless tke backported package has a
dependency on a more recent version of the templates package. But if
this is done too often will lower the advantage of a semi-automatic
templates upgrade with minimal intervention from maintainers of the
'parasite' packages.
> and if you ever added versioned
> dependencies on the template package you would have to make the config
> script detect that it was running with templates from an older version
> of the package and abort.
>
This does not look easy ...
> There may be other cases that would be broken that I'm not thinking of
> right now.
>
We are in time of thinking and testing about all these possible problems.
Nothing of this is expected to go into sarge. Both methods have advantages
and disadvantages.
I think that the other method, template adding at build time is reasonable
when parasiting packages are few and are actively maintained, so changes
propagate fastly. For that reason, adding debhelper support for this method
seems to me a good thing, thanks for have it planned. The annoyance
(bugs and buildd load) caused by this method should not be higher than the
currently caused by the l10n bug reports, the only diference is that a big
part of the bug filing role will be moved from translation teams to the
master templates package maintainer.
When the number of packages parasiting a question is relatively high, I tend
to prefer the register method, seems nicer to the buildds and better to deal
with a bunch of very differently maintained packages. But this currently needs
a lot more ellaboration and testing, to make sure that its limitations do not
completely rule it out, but I think it currently deserves this testing.
This also needs reasonably stable templates (better wording, new
translations are O.K., but if new version dependent stuff is added, the
template name should probably be changed)
Cheers,
--
Agustin
Reply to: