Re: Bug#483418: Not limit dpkg-divert to install but valid also for upgrade in app.

2008-07-06 Thread Raphael Hertzog
On Sun, 06 Jul 2008, Russ Allbery wrote:
> 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.

It looks fine, yes.

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Re: Bug#483418: Not limit dpkg-divert to install but valid also for upgrade in app.

2008-07-06 Thread Russ Allbery
Thanks for the review!

Raphael Hertzog <[EMAIL PROTECTED]> writes:
> On Sat, 05 Jul 2008, Russ Allbery wrote:

>>  The postrm has to do the reverse:
>>  
>> -  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 smailwrapper package wishes to
install a wrapper around /usr/sbin/smail:

-  if [ install = "$1"  ]; then
- dpkg-divert --package smailwrapper --add --rename \
---divert /usr/sbin/smail.real /usr/sbin/smail
-  fi
-Testing $1 is necessary so that the script
-   doesn't try to add the diversion again when
-   smailwrapper is upgraded.  The --package
-   smailwrapper ensures that smailwrapper's
-   copy of /usr/sbin/smail 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
+The --package smailwrapper ensures that
+   smailwrapper's copy of /usr/sbin/smail
+   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
+   dpkg-divert will display a message.  To suppress that
+   message, make the command conditional on the version from which
+   the package is being upgraded:
+   
+   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
+where 1.0-2 is the version at which the
+   diversion was first added to the package.  Running the command
+   during abort-upgrade is pointless but harmless.
   
 
   
The postrm has to do the reverse:

-  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
+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):
+   
+  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
-   
+where 1.02-2 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.
   
 
   

-- 
Russ Allbery ([EMAIL PROTECTED])   


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Re: Bug#483418: Not limit dpkg-divert to install but valid also for upgrade in app.

2008-07-05 Thread Russ Allbery
Please check the following patch, which attempts to clarify how dpkg
diversions should be handled.  Once I started digging into this, the cases
looked more complex than I had expected.  I tried to add more language to
explain the whole situation on the grounds that if I found it confusing,
other people almost certainly also do.

diff --git a/policy.sgml b/policy.sgml
index 24c9072..0cd241a 100644
--- a/policy.sgml
+++ b/policy.sgml
@@ -10564,26 +10564,37 @@ install-info --quiet --remove 
/usr/share/info/foobar.info
supposing that a smailwrapper package wishes to
install a wrapper around /usr/sbin/smail:

-  if [ install = "$1"  ]; then
- dpkg-divert --package smailwrapper --add --rename \
---divert /usr/sbin/smail.real /usr/sbin/smail
-  fi
-Testing $1 is necessary so that the script
-   doesn't try to add the diversion again when
-   smailwrapper is upgraded.  The --package
-   smailwrapper ensures that smailwrapper's
-   copy of /usr/sbin/smail 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
+The --package smailwrapper ensures that
+   smailwrapper's copy of /usr/sbin/smail
+   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
+   dpkg-divert will display a message.  To suppress that
+   message, make the command conditional on the version from which
+   the package is being upgraded:
+   
+   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
+where 1.0-2 is the version at which the
+   diversion was first added to the package.  Running the command
+   during abort-upgrade is pointless but harmless.
   
 
   
The postrm has to do the reverse:

-  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
-   
+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.
   
 
   

-- 
Russ Allbery ([EMAIL PROTECTED])   


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]