FAQ Search Today's Posts Mark Forums Read

» Linux Archive
Home
New Posts
Search
FAQ


Go Back   Linux Archive > Debian > Debian dpkg

 
 
LinkBack Thread Tools
 
Old 06-02-2008, 09:29 PM
Russ Allbery
 
Default debian-policy: Not limit dpkg-divert to install but valid also for upgrade in app. G

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/>


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 06-18-2008, 01:23 PM
Sven Joachim
 
Default debian-policy: Not limit dpkg-divert to install but valid also for upgrade in app. G

On 2008-06-18 13:45 +0200, Raphael Hertzog wrote:

> On Mon, 02 Jun 2008, Russ Allbery wrote:
>> 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.

For the record, running it in the "upgrade" case cannot work at all,
because the new preinst is run _before_ the old postrm. See #486446 for
an example.

Sven


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 

Thread Tools




All times are GMT. The time now is 06:10 AM.

VBulletin, Copyright ©2000 - 2008, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org