Package: lintian
Version: 2.3.1
Severity: wishlist
Hi,
I don't know enough about lintian myself to write the tests below but
I think it would be good to have them. Any help writing them would be
welcome by me.
Policy 8.2 is there to ensure upgrades of library packages will go
smoothly even when the SONAME of the library (and therefore package
name) changes. While strictly speaking policy 8.2 is only violated
once you do have such a SONAME change and then file overwrite
conflicts I do believe maintainers should be warned before the fact.
I guess the first thing to test is that we are dealing with a library
package. I think a shlibs or symbols file would be a reliable
indicator. A library package without them would be buggy already. The
other common check needed would be to test if a path/name contains the
version of the library, e.g. /etc/gtk-2.0/. This one is harder and
probably impossible to get perfect. But covering the obvious cases
would be a start.
So say we do have a library package then the following should be
checked:
1) binaries in library packages
Anything in /bin, /sbin, /usr/bin or /usr/sbin will cause a file
overwrite conflict when the SONAME is changed. Binaries should be
placed in a lib<name>-bin package. That way lib<name>1, lib<name>2 and
lib<name>-bin can be installed at the same time during the transition
to a new SONAME and reverse depends can be upgraded one by one. There
could be a binaries called <binary>-<version> but that is rare and
/usr/lib/lib<name>/<binary> might be better.
Note: Under multiarch /usr/lib/triplet/lib<name>/<binary> still works
while /usr/bin/<binary>-<version> gives a file overwrite conflict.
2) conffiles in library packages
I believe this to be a verry bad idea unless the conffile is specific
to the major version of the library, which is also a bad idea (e.g. I
don't see why /etc/gtk-2.0/im-multipress.conf should be specific to
gtk-2.0). Besides causing a file overwrite conflict this also moves a
conffile from one package to another requireing special care in the
maintainer scripts. The same holds with a conffile is in a version
specific directory. Without special care changes the user made to the
old file will not show up in the new file and users will be surprised
the conffile moved. I think it would be best to recommend moving the
conffile into a lib<name>-conf (if architecture dependent) or
lib<name>-common (if architecture independent) package.
3) shared files in library pckages
Manpage, locales, data files, ... in /usr/share also create file
overwrite conflicts unless they have a versioned path/name. Those
files should be moved into lib<name>-common. /usr/share/doc/<package>
is specifically ok there as it always contains a version via the
package name (but see note below).
Note: Under multiarch files in /usr/share will not cause a conflict IF
they are bit identical. If they contain anything that differs between
builds (e.g. buildd hostname, timestamp, etc as comment) then they
will conflict too.
For multiarch some additional tests would be helpfull.
4) 'Multi-Arch: foreign' with public shared library
The Multi-Arch: foreign specifically says that the package is a binary
package and contains no public shared libraries. Therefore any shlibs
or symbols file means something is verry wrong.
5) 'Multi-Arch: same' with files outside multiarch dirs
The Multi-Arch: same says the package can be installed for multiple
architectures at the same time. For that to work the package must have
no files with identical path/name for different architectures. The
only exception to this is when files are bit identical, which
specifically covers, but not limited to, the /usr/share/doc/package/*
files required in every package. Files that are bit identical between
architectures are usualy in /usr/share so that directory should be
ignored completly for this test. Files in $PATH may also be
architecture independent if they are scripts. Anything starting with
"#!" should be ignored. I think anything else that does not contain a
triplet in its path/name should be reported.
Specificaly conffiles will pose a problem here I think. The conffile
will belong to multiple packages then causing the first problem for
dpkg. Then on conffile changes the change will happen multiple times,
once per architecture and the changes made by the first arch upgraded
will look like the user made changes to the conffile in other
archs. Overall a big mess. Best to forbid conffiles in 'Multi-Arch:
same' packages unless they contain a triplet in its path/name.
So anyone willing and able to write some code for these tests?
MfG
Goswin
PS: If you only work on parts of this please clone and retitle
appropriatly.
-- System Information:
Debian Release: squeeze/sid
APT prefers unstable
APT policy: (500, 'unstable'), (499, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.29.4-frosties-2 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=de_DE (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/bash
Versions of packages lintian depends on:
ii binutils 2.20-5 The GNU assembler, linker and bina
ii diffstat 1.47-1 produces graph of changes introduc
ii dpkg-dev 1.15.5.6 Debian package development tools
ii file 5.03-5 Determines file type using "magic"
ii gettext 0.17-8 GNU Internationalization utilities
ii intltool-debian 0.35.0+20060710.1 Help i18n of RFC822 compliant conf
ii libapt-pkg-perl 0.1.24 Perl interface to libapt-pkg
ii libclass-accessor-perl 0.34-1 Perl module that automatically gen
ii libipc-run-perl 0.84-1 Perl module for running processes
ii libparse-debianchangel 1.1.1-2 parse Debian changelogs and output
ii libtimedate-perl 1.2000-1 collection of modules to manipulat
ii liburi-perl 1.52-1 module to manipulate and access UR
ii man-db 2.5.6-5 on-line manual pager
ii perl [libdigest-sha-pe 5.10.1-9 Larry Wall's Practical Extraction
lintian recommends no packages.
Versions of packages lintian suggests:
ii binutils-multiarch 2.20-5 Binary utilities that support mult
ii libtext-template-perl 1.45-1 Text::Template perl module
ii man-db 2.5.6-5 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
