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 <[EMAIL PROTECTED]> 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
