Thanks for the review!
Raphael Hertzog <hertzog@debian.org> writes:
> On Sat, 05 Jul 2008, Russ Allbery wrote:
>> The postrm has to do the reverse:
>> <example>
>> - if [ remove = "$1" ]; then
>> + if [ remove = "$1" -o abort-install = "$1" -o disappear = "$1" ]; then
> To be really complete we should also handle the abort-upgrade if the old
> version had no diversion... but that would make it too complicated for
> its purpose.
Oh, hm, yes, the new postrm abort-upgrade is called in a useful place for
it to fix this. But the abort-upgrade case would need to test the version
number from which we're upgrading to determine whether to roll back the
diversion.
Since this is Policy (even an appendix), and since the failure case is
what people most frequently get wrong, I think I'd like to try to capture
the whole situation. Do you think that something like this is more
confusing than it's worth? I think it is the fully correct handling.
diff --git a/policy.sgml b/policy.sgml
index 7d54e29..5975d37 100644
--- a/policy.sgml
+++ b/policy.sgml
@@ -10550,26 +10550,48 @@ install-info --quiet --remove /usr/share/info/foobar.info
supposing that a <prgn>smailwrapper</prgn> package wishes to
install a wrapper around <file>/usr/sbin/smail</file>:
<example>
- if [ install = "$1" ]; then
- dpkg-divert --package smailwrapper --add --rename
- --divert /usr/sbin/smail.real /usr/sbin/smail
- fi
- </example> Testing <tt>$1</tt> is necessary so that the script
- doesn't try to add the diversion again when
- <prgn>smailwrapper</prgn> is upgraded. The <tt>--package
- smailwrapper</tt> ensures that <prgn>smailwrapper</prgn>'s
- copy of <file>/usr/sbin/smail</file> can bypass the diversion and
- get installed as the true version.
+ dpkg-divert --package smailwrapper --add --rename
+ --divert /usr/sbin/smail.real /usr/sbin/smail
+ </example> The <tt>--package smailwrapper</tt> ensures that
+ <prgn>smailwrapper</prgn>'s copy of <file>/usr/sbin/smail</file>
+ can bypass the diversion and get installed as the true version.
+ It's safe to add the diversion unconditionally on upgrades since
+ it will be left unchanged if it already exists, but
+ <prgn>dpkg-divert</prgn> will display a message. To suppress that
+ message, make the command conditional on the version from which
+ the package is being upgraded:
+ <example>
+ if [ upgrade != "$1" ] || dpkg --compare-versions "$2" lt 1.0-2; then
+ dpkg-divert --package smailwrapper --add --rename
+ --divert /usr/sbin/smail.real /usr/sbin/smail
+ fi
+ </example> where <tt>1.0-2</tt> is the version at which the
+ diversion was first added to the package. Running the command
+ during abort-upgrade is pointless but harmless.
</p>
<p>
The postrm has to do the reverse:
<example>
- if [ remove = "$1" ]; then
+ if [ remove = "$1" -o abort-install = "$1" -o disappear = "$1" ]; then
+ dpkg-divert --package smailwrapper --remove --rename
+ --divert /usr/sbin/smail.real /usr/sbin/smail
+ fi
+ </example> If the diversion was added at a particular version, the
+ postrm should also handle the failure case of upgrading from an
+ older version (unless the older version is so old that direct
+ upgrades are no longer supported):
+ <example>
+ if [ abort-upgrade = "$1" ] && dpkg --compare-versions "$2" lt 1.0-2; then
dpkg-divert --package smailwrapper --remove --rename
--divert /usr/sbin/smail.real /usr/sbin/smail
fi
- </example>
+ </example> where <tt>1.02-2</tt> is the version at which the
+ diversion was first added to the package. The postrm should not
+ remove the diversion on upgrades both because there's no reason to
+ remove the diversion only to immediately re-add it and since the
+ postrm of the old package is run after unpacking so the removal of
+ the diversion will fail.
</p>
<p>
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Bug#483418: Not limit dpkg-divert to install but valid also for upgrade in app.
