Mass bugfiling in preparation for multiarch
Hi,
over the weekend I did some work on multiarch again and did notice
some new and old problems when adding more libraries to my test set.
Given that the problems are quite easily detectable I'm considering
scanning all packages for their occurance and reporting bugs for them.
In detail I'm looking for the following situations violating 'Policy
8.2 Shared library support files':
1) Library packages that contain public binary ([/usr]/[s]bin/*)
Policy 8.2 says:
| If your package contains files whose names do not change with each
| change in the library shared object version, you must not put them in
| the shared library package. Otherwise, several versions of the shared
| library cannot be installed at the same time without filename clashes,
| making upgrades and transitions unnecessarily difficult.
Example: libc6 contains /usr/sbin/zic, /usr/bin/getent and several more
libc6 must be split into libc-bin and libc6 packages.
2) Library packages that contain conffiles
First Policy 8.2. If the conffiles are not named in a way that changes
with each soname change then this is a violation of a MUST directive.
Example: libc6 conatins /etc/gai.conf
Secondly even conffiles with unique names will be a problem for
multiarch. The library package would be installed from i386
and amd64 resulting in 2 debs with the same conffile.
Example: libgtk2.0-0 contains /etc/gtk-2.0/im-multipress.conf
For this I want to file bugs (on top of violations of the MUST
directive) requesting that either the conffile is split into a
seperate package (say you already have a libfoo and foo-bin package)
or made unique for the target:
/etc/gtk-2.0-x86_64-linux-gnu/im-multipress.conf.
3) Library packages that contain shared files
Policy 8.2 goes on to say this about shared files:
| If the program or file is architecture independent, the
| recommendation is for it to be placed in a subdirectory of
| /usr/share instead, preferably under
| /usr/share/package-name. Following the package-name naming
| convention ensures that the file names change when the shared object
| version changes.
But the MUST directive of 8.2 still remains and packages not using a
/usr/share/package-name but something more generic are in violation.
Example: libasound2 contains /usr/share/alsa/alsa.conf
libarts1c2a conatins /usr/share/man/man1/artsdsp.1.gz
Again for multiarch this becomes more complicated.
/usr/share/package-name will still cause a conflict between the i386
and amd64 flavour of a library package. For this I want to file bugs
(again on top of the violations of the MUST directive) requesting that
either the shared data is split out into libfoo-common packages or, in
case of verry small files, moved out of shared into the multiarch
library path: /usr/lib/x86_64-linux-gnu/package/.
Example: libdirectfb-1.0-0 contains /usr/share/directfb-1.0.1/cursor.dat
Any objections to this? Note that most will be violations of a MUST
directive of policy.
MfG
Goswin
Reply to: