On Monday 11 June 2007 22:36, Christoph Berg wrote: > As a test implementation, I modified the post{inst,rm} templates in > the tex-common package [2] and rebuilt texlive-lang-* using that. dpkg > -i texlive-lang-*.deb takes over 4 minutes in the old version, but > only a total of 60s with postpone used (35s for dpkg -i plus 25s for > the background jobs).
To be honest, this is exactly an example where I would *NOT* want to see this implemented. A major downside of the mechanism supported by this package is that there is absolutely no check is any errors occur during the running of these postponed scripts! In the case of texlive, failure in the script currently leaves the package "unconfigured", which is correct as it may not be usable [1]. Using the mechanism proposed here, the package would happily get the status "fully installed" and the user would be none the wiser why he'd get all these inexplicable errors while using the software. > There's a few other postinst/postrm jobs that could benefit from > postpone: > > * [...] The only case where IMO using this mechanism could be considered is if failure of the scripts to run correctly has no or only extremely minor consequences for the correct working of the software, as is I guess the case for update-menu. For all other potential use cases, maintainers should wait for the implementation of triggers in dpkg [2], which is the only correct way to deal with this issue. Cheers, FJP [1] And that this is not purely theoretical can be shown with the recent RC bugs (#419020 and friends) against jadetex, which caused failure in the postinst for all texlive packages which call such scripts. [2] http://lists.debian.org/debian-dpkg/2007/04/msg00006.html
pgp27VaYadMXA.pgp
Description: PGP signature