Re: debian-policy: Not limit dpkg-divert to install but valid also for upgrade in app. G
(leaving again full context as my reply is quite late)
On Mon, 02 Jun 2008, Russ Allbery wrote:
> 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.
I tend to agree, I can't imagine a scenario where it would be a bad thing
to do.
But we certainly don't want to temporarily remove the diversion on upgrade
so this is ok only for the preinst part. The postrm part shall stay
restricted to the "remove" case.
Cheers,
--
Raphaël Hertzog
Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/
Reply to: