Package: lintian Version: 2.4.3 Severity: normal Hello,
I don't think that breaks-without-version makes much sense, especially after policy 3.9.0 has clarified Replaces/Breaks/Conflicts usage. At least, it should not be a "warning" as it says nothing about quality of the package and in many cases it could be misleading. Breaks is more package manager friendly relationship when it comes to upgrades and there is absolutely nothing wrong with having Breaks without version in almost all (if not all) cases when Replaces for the same package is also present. One of the most common example from my experience is the following: Suppose you want to split a package (app-common) into smaller parts (app-data and app-doc). Then a very apt-friendly approach (in the spirit of policy 3.9.0) would be: Package: app-data Replaces: app-common Breaks: app-common Package: app-doc Replaces: app-common Breaks: app-common However, instead lintian suggests using Conflicts here which clearly contradicts policy 7.4 recommendation: ------------------------------------------------------------------------------ Normally, Breaks should be used instead of Conflicts since Conflicts imposes a stronger restriction on the ordering of package installation or upgrade and can make it more difficult for the package manager to find a correct solution to an upgrade or installation problem. Breaks should be used: * when moving a file from one package to another (see Overwriting files and replacing packages - Replaces, Section 7.6), * when splitting a package (a special case of the previous one), or .... ------------------------------------------------------------------------------ I could also think of more examples with moving of files if needed. So generally I have a couple of suggestions here. They are listed in the order of my preference: * Drop breaks-without-version completely (at least for 3.9.0 compliant packages). * Do not emit breaks-without-version when the same package is found in Replaces field (provided it's not Breaks/Replaces against itself). Though I still prefer complete removal of breaks-without-version as I don't believe it makes much sense in general (as it's worded) and it's too prone to false positives. * Downgrade breaks-without-version to info/pedantic level. This would be the worst case scenario but I could probably accept it as I generally do not care much about false positives at those levels. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (100, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.36-trunk-amd64 (SMP w/4 CPU cores) Locale: LANG=lt_LT.UTF-8, LC_CTYPE=lt_LT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages lintian depends on: ii binutils 2.20.1-15 The GNU assembler, linker and bina ii diffstat 1.53-1 produces graph of changes introduc ii dpkg-dev 1.15.8.6 Debian package development tools ii file 5.04-5 Determines file type using "magic" ii gettext 0.18.1.1-3 GNU Internationalization utilities ii intltool-debian 0.35.0+20060710.1 Help i18n of RFC822 compliant conf ii libapt-pkg-perl 0.1.24+b1 Perl interface to libapt-pkg ii libclass-accessor-perl 0.34-1 Perl module that automatically gen ii libipc-run-perl 0.89-1 Perl module for running processes ii libparse-debianchangel 1.1.1-2.1 parse Debian changelogs and output ii libtimedate-perl 1.2000-1 collection of modules to manipulat ii liburi-perl 1.56-1 module to manipulate and access UR ii locales 2.11.2-7 Embedded GNU C Library: National L ii man-db 2.5.7-6 on-line manual pager ii perl [libdigest-sha-pe 5.10.1-16 Larry Wall's Practical Extraction lintian recommends no packages. Versions of packages lintian suggests: ii binutils-multiarch 2.20.1-15 Binary utilities that support mult pn libtext-template-perl <none> (no description available) ii man-db 2.5.7-6 on-line manual pager -- 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
