Re: Finding out in postinst whether some other package is configured

[Wouter Verhelst <wouter@debian.org>]

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