Olivier Berger <[EMAIL PROTECTED]> 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 ([EMAIL PROTECTED])               <http://www.eyrie.org/~eagle/>


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

Reply via email to