Re: debian-policy: Not limit dpkg-divert to install but valid also for upgrade in app. G

[Russ Allbery <rra@debian.org>]

Olivier Berger <olivier.berger@it-sudparis.eu> writes:

> Package: debian-policy
> Version: 3.7.3.0
> Severity: minor
>
> In "Appendix G - Diversions - overriding a package's version of a file
> (from old Packaging Manual)", there's some misleading explanations on
> dpkg-divert preferred use in presint scriptsi (as I understand it, this
> is not related to policy itself, as it lies in the appendix, so this
> issue should be easily fixed ?).
>
> The following example is provided with a sentence which seems erronous
> to me ATM :
>
>        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.
>
> IMHO, whenever a package introduces a diversion for the first time,
> whereas previous versions of the package may have been installed,
> there's a need to add the diversion on upgrade too.  Running dpkg-divert
> twice in a row with the same arguments doesn't harm, at the moment from
> the tests I've done on a "testing" system.
>
> Maybe this used to be different in ancient times and diverting several
> times would lead to chaos ?
>
> So I suggest that the example is changed to something like :
>
> 	case "$1" in
>     		install|upgrade)
> 			dpkg-divert --package smailwrapper --add --rename \
> 	                      --divert /usr/sbin/smail.real /usr/sbin/smail
> 	        ;;
>
> without further explanations by removing the sentence in question.

This sounds reasonable to me, and the packages I checked that use
diversions add the diversion on both install and upgrade.  I'm inclined to
make this change.  dpkg maintainers, could you double-check and be sure
that I'm not missing something?

And, actually, should we just remove the if or case guard entirely and
just run dpkg-divert unconditionally in preinst?  The only difference at
that point is abort-upgrade, and if the new version of the package was
removing diversions in its preinst, re-establishing the diversion is the
right thing to do.  I'm remembering Ian's previous comments that normally
one should not be testing the action in maintainer scripts.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>