Re: Finding out in postinst whether some other package is configured
Op ma, 17-10-2005 te 16:17 +0200, schreef Frank Küster:
> Hi Wouter,
>
> thanks for your answer - did you reply to me instead to the list on
> purpose?
Uh, no -- sorry.
> If you want, you can cite me on the list.
Here goes :)
> Wouter Verhelst <wouter@debian.org> wrote:
>
> >> The big problem with that is that if such a command ever fails, how does
> >> the package system know which package caused the error? It could be the
> >> one that first registered the call, but also an other package that would
> >> have added it to the journal if it hadn't been there yet.
> >
> > How is that worse than the current situation?
> >
> > Consider:
> >
> > apt-get install xfonts-*
> >
> > They all run something to update the fonts. The first one did something
> > wrong, so its postinst fails on updating the fonts, and the package is
> > marked as unconfigured (or is it half-configured? not sure).
> >
> > The next package, however, tries to run the same command (updating the
> > font cache), but the files from the first package are /still/ there.
> > Hence, its postinst also fails, and this package is also marked as
> > half-/unconfigured.
> >
> > The proposed situation would basically result in the same thing, with
> > the exception that on average, the number of packages in a
> > half-/unconfigured state would be larger.
>
> There's an other difference: By inspecting the dpkg log, it is currently
> plain to see which package failed first. If all would be done in a
> dpkg-post-run hook, it would require some debugging to even know which
> package to blame. Putting this debugging load on the maintainer of an
> arbitrary package the user chooses (and on the inexperienced user),
> instead of the responsible maintainer, is not only "unjust", it is very
> ineffective.
>
> > All that being said, I believe this problem can be solved. All examples
> > I've seen where such a mechanism would be interesting involve
> > regenerating some cache or other based on the added files by some
> > packages.
>
> ACK.
>
> > Might it not be feasible to require that packages call the
> > (hypothetical) dpkg-run-once command with the list of files it added;
> > that the command which is actually ran once gets that list of files; and
> > that if something goes wrong, it outputs the name(s) of the package(s)
> > which made the run fail?
>
> I don't think so. E.g. in the case of mktexlsr and updmap-sys, two
> candidates from the tetex-bin package, this wouldn't work (at least not
> well).
>
> mktexlsr as provided by upstream just stores the "ls -R" output of a
> directory tree in a ls-R file at the tree root. To work with a list of
> added files, we would have to develop a completely new, Debian-specific
> tool to edit these files.
>
> updmap-sys takes a configuration file (which has gotten some new lines
> after the new package put a file in /etc/texmf/updmap.d/ and ran
> update-updmap), checks whether all fonts referenced in the configuration
> file are actually present, and generates a couple of font
> "configuration" files of different syntax (for different programs) in
> /var/lib/texmf/fonts. There's a sophisticated mechanism that makes sure
> that files of removed-but-not-purged packages in the updmap.d directory
> do no harm; this cannot be achieved easily when running a dpkg-post-run
> hook with a list on the command line.
>
> Regards, Frank
--
The amount of time between slipping on the peel and landing on the
pavement is precisely one bananosecond
Reply to: