Bug#483418: debian-policy: Not limit dpkg-divert to install but valid also for upgrade in app. G
Hi Russ, Russ Allbery schrieb am Sat 05. Jul, 15:49 (-0700): Jörg Sommer [EMAIL PROTECTED] writes: 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 By the way, the example should not suggest to use a fixed prefix, but the package name. Because there might be more than one diversion which would clash. I believe it's not permissible to divert the same file more than once. I don't know. It's possible and who should prohibit it? Bye, Jörg. -- Als deutscher Tourist im Ausland steht man vor der Frage, ob man sich anständig benehmen muss oder ob schon deutsche Touristen dagewesen sind. (Kurt Tucholsky) signature.asc Description: Digital signature http://en.wikipedia.org/wiki/OpenPGP
Bug#483418: debian-policy: Not limit dpkg-divert to install but valid also for upgrade in app. G
Jörg Sommer [EMAIL PROTECTED] writes: Russ Allbery schrieb am Sat 05. Jul, 15:49 (-0700): I believe it's not permissible to divert the same file more than once. I don't know. It's possible and who should prohibit it? I'm fairly sure that you'll find that dpkg-divert prohibits it, thus making it impossible. windlord:/usr/bin# dpkg-divert --list | grep perldoc diversion of /usr/bin/perldoc to /usr/bin/perldoc.stub by perl-doc windlord:/usr/bin# dpkg-divert --divert /usr/bin/perldoc.extra --package perl-extra /usr/bin/perldoc dpkg-divert: `diversion of /usr/bin/perldoc to /usr/bin/perldoc.extra by perl-extra' clashes with `diversion of /usr/bin/perldoc to /usr/bin/perldoc.stub by perl-doc' -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#483418: debian-policy: Not limit dpkg-divert to install but valid also for upgrade in app. G
Hi Russ, Russ Allbery schrieb am Mon 07. Jul, 11:43 (-0700): Jörg Sommer [EMAIL PROTECTED] writes: Russ Allbery schrieb am Sat 05. Jul, 15:49 (-0700): I believe it's not permissible to divert the same file more than once. I don't know. It's possible and who should prohibit it? I'm fairly sure that you'll find that dpkg-divert prohibits it, thus making it impossible. windlord:/usr/bin# dpkg-divert --list | grep perldoc diversion of /usr/bin/perldoc to /usr/bin/perldoc.stub by perl-doc windlord:/usr/bin# dpkg-divert --divert /usr/bin/perldoc.extra --package perl-extra /usr/bin/perldoc dpkg-divert: `diversion of /usr/bin/perldoc to /usr/bin/perldoc.extra by perl-extra' clashes with `diversion of /usr/bin/perldoc to /usr/bin/perldoc.stub by perl-doc' Ahh, okay. I said nothing. Bye, Jörg. -- Angenehme Worte sind nie wahr, wahre Worte sind nie angenehm. signature.asc Description: Digital signature http://en.wikipedia.org/wiki/OpenPGP
Bug#483418: debian-policy: Not limit dpkg-divert to install but valid also for upgrade in app. G
Jörg Sommer [EMAIL PROTECTED] writes: 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 By the way, the example should not suggest to use a fixed prefix, but the package name. Because there might be more than one diversion which would clash. I believe it's not permissible to divert the same file more than once. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#483418: 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 [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. 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/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#483418: 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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#483418: debian-policy: Not limit dpkg-divert to install but valid also for upgrade in app. G
Hello, Olivier Berger schrieb am Wed 28. May, 20:32 (+0200): 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 By the way, the example should not suggest to use a fixed prefix, but the package name. Because there might be more than one diversion which would clash. Bye, Jörg. -- „Dass man etwas durchdringen kann, wenn man es durchschaut hat, ist der Irrtum der Fliege an der Fensterscheibe.“ (Nietzsche) signature.asc Description: Digital signature http://en.wikipedia.org/wiki/OpenPGP
Bug#483418: debian-policy: Not limit dpkg-divert to install but valid also for upgrade in app. G
Hi, I think it is time to drop the appendices from the policy manual proper, and at least put them into a separate document (obsolete dpkg documentation), or move them into dpkg itself, since these appendices are not normative, and unmaintained, they should be part of dpkg extended documentation, since they certainly are not policy. manoj -- OS/2 must die! Manoj Srivastava [EMAIL PROTECTED] http://www.golden-gryphon.com/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#483418: debian-policy: Not limit dpkg-divert to install but valid also for upgrade in app. G
Manoj Srivastava [EMAIL PROTECTED] writes: I think it is time to drop the appendices from the policy manual proper, and at least put them into a separate document (obsolete dpkg documentation), or move them into dpkg itself, since these appendices are not normative, and unmaintained, they should be part of dpkg extended documentation, since they certainly are not policy. I agree. I can look at breaking them out for the next release of Policy, and then once they're in a separate document, it's easier to talk to the dpkg maintainers about where they should go and who should maintain them and how to do that transition. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#483418: debian-policy: Not limit dpkg-divert to install but valid also for upgrade in app. G
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]
Bug#483418: debian-policy: Not limit dpkg-divert to install but valid also for upgrade in app. G
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. Hope this helps. Best regards, -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.24-openvz-24-004.1d1-686 (SMP w/2 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
