Bug#578854: debian-policy: Wording about Conflicts needs to be clarified
On Fri, Apr 23, 2010 at 05:09:36PM +0200, Goswin von Brederlow wrote: Up to now, I always used Conflicts for explicit file conflicts and used Breaks for other subtle breakages (interface/API change). So when moving files from one package to the other I used Conflicts: previous ( last-version) and Replaces: previous ( last-version) on the package where the files are. Conflicts is always right for file conflicts, and in that case should also *always* be accompanied by Replaces. The biggest problem, which the Policy wording tries to address, is the use of bare Conflicts, for things that aren't file conflicts: in that case, a versioned conflicts is almost always wrong because what you really mean to express is a versioned Breaks. And it's *that* usage of versioned Conflicts which causes the most problem for the package manager. How about this? In 7.3 replace If the breaking package also overwrites some files from the older package, it should use Replaces (not Conflicts) to ensure this goes smoothly. with If the breaking package also overwrites some files from the older package, it must use a less than versioned Conflicts (not Breaks) to ensure both upgrades and downgrades go smoothly. I'm not sure I have an informed opinion about this section, yet. And there's a separate bug report about this paragraph, which I think we should use to track this questino separately. And in 7.4 replace A Conflicts entry should almost never have an earlier than version clause. This would prevent dpkg from upgrading or installing the package which declared such a conflict until the upgrade or removal of the conflicted-with package had been completed. Instead, Breaks may be used. with A Conflicts entry should only have an earlier than version clause if it coincides with a Replaces clause of the same package and version. A Conflicts with an earlier than version clause without Replaces clause is almost always better done as Breaks. I think the middle sentence explaining the rationale should be retained. Aside from that, I think your wording is an improvement. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#578854: debian-policy: Wording about Conflicts needs to be clarified
On Fri, Apr 23, 2010 at 12:04:12PM +0300, Eugene V. Lyubimkin wrote: On Friday 23 April 2010 11:35:16 Steve Langasek wrote: On Fri, Apr 23, 2010 at 09:27:32AM +0200, Raphaël Hertzog wrote: No, it definitely isn't ok. Versioned conflicts still impose significant constraints on calculating an upgrade path between releases and contribute to upgrade failures. I disagree. Using versioned Conflicts+Replaces for upgrades don't impose any additional constraints to calculating upgrade path. I explicitly was not talking about the case where Conflicts are used together with Replaces. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#578854: debian-policy: Wording about Conflicts needs to be clarified
Package: debian-policy Version: 3.8.4.0 Severity: normal I stumbled upon policy 7.4: A Conflicts entry should almost never have an earlier than version clause. This would prevent dpkg from upgrading or installing the package which declared such a conflict until the upgrade or removal of the conflicted-with package had been completed. Instead, Breaks may be used. Looking at this sentence it comes mostly unchanged from the original packaging manual (commit ff1bec10): - A ttConflicts/tt entry should almost never have an - `earlier than' version clause. This would prevent - prgndpkg/prgn from upgrading or installing the package - which declared such a conflict until the upgrade or removal - of the conflicted-with package had been completed. This - aspect of installation ordering is not handled by - prgndselect/prgn, so that the use ttConflicts/tt in - this way is likely to cause problems for `bulk run' upgrades - and installations. I think using an earlier than clause is perfectly ok nowadays and it's possibly the right thing to do when moving files around between packages. That dselect limitation might have been the reason for this statement but I think it's entirely outdated now. Up to now, I always used Conflicts for explicit file conflicts and used Breaks for other subtle breakages (interface/API change). So when moving files from one package to the other I used Conflicts: previous ( last-version) and Replaces: previous ( last-version) on the package where the files are. We need to: 1/ fix that statement IMO 2/ document clearly whether versioned Breaks+Replaces or versioned Conflicts+Replaces ought to be used when moving files around. Cheers, -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (150, 'experimental') Architecture: i386 (x86_64) Kernel: Linux 2.6.32-4-amd64 (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/dash debian-policy depends on no packages. debian-policy recommends no packages. Versions of packages debian-policy suggests: ii doc-base 0.9.5 utilities to manage online documen -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#578854: debian-policy: Wording about Conflicts needs to be clarified
On Friday 23 April 2010 10:27:32 Raphaël Hertzog wrote: 1/ fix that statement IMO Seconded. 2/ document clearly whether versioned Breaks+Replaces or versioned Conflicts+Replaces ought to be used when moving files around. Seconded, with preference to have Conflicts+Replaces for this aim. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#578854: debian-policy: Wording about Conflicts needs to be clarified
On Fri, Apr 23, 2010 at 09:27:32AM +0200, Raphaël Hertzog wrote: I stumbled upon policy 7.4: A Conflicts entry should almost never have an earlier than version clause. This would prevent dpkg from upgrading or installing the package which declared such a conflict until the upgrade or removal of the conflicted-with package had been completed. Instead, Breaks may be used. Looking at this sentence it comes mostly unchanged from the original packaging manual (commit ff1bec10): - A ttConflicts/tt entry should almost never have an - `earlier than' version clause. This would prevent - prgndpkg/prgn from upgrading or installing the package - which declared such a conflict until the upgrade or removal - of the conflicted-with package had been completed. This - aspect of installation ordering is not handled by - prgndselect/prgn, so that the use ttConflicts/tt in - this way is likely to cause problems for `bulk run' upgrades - and installations. I think using an earlier than clause is perfectly ok nowadays and it's possibly the right thing to do when moving files around between packages. No, it definitely isn't ok. Versioned conflicts still impose significant constraints on calculating an upgrade path between releases and contribute to upgrade failures. Up to now, I always used Conflicts for explicit file conflicts and used Breaks for other subtle breakages (interface/API change). So when moving files from one package to the other I used Conflicts: previous ( last-version) and Replaces: previous ( last-version) on the package where the files are. Conflicts is always right for file conflicts, and in that case should also *always* be accompanied by Replaces. The biggest problem, which the Policy wording tries to address, is the use of bare Conflicts, for things that aren't file conflicts: in that case, a versioned conflicts is almost always wrong because what you really mean to express is a versioned Breaks. And it's *that* usage of versioned Conflicts which causes the most problem for the package manager. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#578854: debian-policy: Wording about Conflicts needs to be clarified
On Friday 23 April 2010 11:35:16 Steve Langasek wrote: On Fri, Apr 23, 2010 at 09:27:32AM +0200, Raphaël Hertzog wrote: No, it definitely isn't ok. Versioned conflicts still impose significant constraints on calculating an upgrade path between releases and contribute to upgrade failures. I disagree. Using versioned Conflicts+Replaces for upgrades don't impose any additional constraints to calculating upgrade path. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#578854: debian-policy: Wording about Conflicts needs to be clarified
Steve Langasek vor...@debian.org writes: On Fri, Apr 23, 2010 at 09:27:32AM +0200, Raphaël Hertzog wrote: I stumbled upon policy 7.4: A Conflicts entry should almost never have an earlier than version clause. This would prevent dpkg from upgrading or installing the package which declared such a conflict until the upgrade or removal of the conflicted-with package had been completed. Instead, Breaks may be used. Looking at this sentence it comes mostly unchanged from the original packaging manual (commit ff1bec10): - A ttConflicts/tt entry should almost never have an - `earlier than' version clause. This would prevent - prgndpkg/prgn from upgrading or installing the package - which declared such a conflict until the upgrade or removal - of the conflicted-with package had been completed. This - aspect of installation ordering is not handled by - prgndselect/prgn, so that the use ttConflicts/tt in - this way is likely to cause problems for `bulk run' upgrades - and installations. I think using an earlier than clause is perfectly ok nowadays and it's possibly the right thing to do when moving files around between packages. No, it definitely isn't ok. Versioned conflicts still impose significant constraints on calculating an upgrade path between releases and contribute to upgrade failures. Up to now, I always used Conflicts for explicit file conflicts and used Breaks for other subtle breakages (interface/API change). So when moving files from one package to the other I used Conflicts: previous ( last-version) and Replaces: previous ( last-version) on the package where the files are. Conflicts is always right for file conflicts, and in that case should also *always* be accompanied by Replaces. The biggest problem, which the Policy wording tries to address, is the use of bare Conflicts, for things that aren't file conflicts: in that case, a versioned conflicts is almost always wrong because what you really mean to express is a versioned Breaks. And it's *that* usage of versioned Conflicts which causes the most problem for the package manager. How about this? In 7.3 replace If the breaking package also overwrites some files from the older package, it should use Replaces (not Conflicts) to ensure this goes smoothly. with If the breaking package also overwrites some files from the older package, it must use a less than versioned Conflicts (not Breaks) to ensure both upgrades and downgrades go smoothly. And in 7.4 replace A Conflicts entry should almost never have an earlier than version clause. This would prevent dpkg from upgrading or installing the package which declared such a conflict until the upgrade or removal of the conflicted-with package had been completed. Instead, Breaks may be used. with A Conflicts entry should only have an earlier than version clause if it coincides with a Replaces clause of the same package and version. A Conflicts with an earlier than version clause without Replaces clause is almost always better done as Breaks. MfG Goswin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#578854: Bug# 578854: debian-policy: Wording about Conflicts needs to be clarified
2/ document clearly whether versioned Breaks+Replaces or versioned Conflicts+Replaces ought to be used when moving files around. Seconded, with preference to have Conflicts+Replaces for this aim. Out of conclusion of discussion in #578854, I slightly change my position for second point to 'use Conflicts+Replaces, unless the replaced package is Essential, for which use Breaks+Replaces'. -- Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com C++/Perl developer, Debian Developer signature.asc Description: OpenPGP digital signature
