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
Attachment:
pgpZ71xMK8PUW.pgp
Description: PGP signature