tags 650445 + patch
thanks
* Goswin von Brederlow <goswin-...@web.de>, 2010-01-29, 16:11:
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.
I propose the attached patch to detect arch-specific files outside
multiarch-directories. It use quite different tactics than Goswin, but
has an advantage of detecting most of the issues and producing no false
positives (for the current state of the archive).
I ran lintian (with the patch applied) against all i386 multi-arch:same
packages in the archive, and then compared it with what
http://people.debian.org/~jwilk/multi-arch/same-md5sums.txt reports.
The only undetected problems were in the following files:
- shell scripts, *.desktop files, *.applications files and menu files with
embedded multi-arch paths[0];
- header files that differ across architectures;
- stuff in /usr/share/{doc,info,locale,lintian,man}/;
- some *.jar files that were generated at build time (and thus has
timestamps embedded).
Of course, the patch description needs improvement. (Patches to the
patch welcome! :P)
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.
Is it really how it's implement in dpkg? I seriously doubt it.
--
Jakub Wilk
diff --git a/checks/binaries b/checks/binaries
--- a/checks/binaries
+++ b/checks/binaries
@@ -128,7 +128,10 @@
my $proc = shift;
my $arch;
+my $multiarch;
my $madir;
+my $gnu_triplet_re;
+my $ruby_triplet_re;
my $dynsyms = 0;
my $needs_libc = '';
my $needs_libc_file;
@@ -140,6 +143,7 @@
my %SONAME;
$arch = $info->field('architecture')//'';
+$multiarch = $info->field('multi-arch')//'no';
my $srcpkg = $proc->pkg_src()//'';
foreach my $file (sort keys %{$info->objdump_info}) {
@@ -184,6 +188,12 @@
# nsswitch modules
$madir = $MULTIARCH_DIRS->value($arch);
+$gnu_triplet_re = quotemeta $madir;
+$gnu_triplet_re =~ s,^i386,i[3-6]86,;
+$ruby_triplet_re = $gnu_triplet_re;
+$ruby_triplet_re =~ s,linux\\-gnu$,linux,;
+$ruby_triplet_re =~ s,linux\\-gnu,linux\\-,;
+
# In the (unlikely) case that the architecture is unknown (or we do
# not know the multi-arch path for a known architecture) , we assume
# it the multi-arch path to be this (hopefully!) non-existent path to
@@ -267,6 +277,12 @@
tag 'arch-dependent-file-in-usr-share', $file;
}
+ if ($multiarch eq 'same') {
+ unless ($file =~ m,/(?:$gnu_triplet_re|$ruby_triplet_re|java-\d+-openjdk-\Q$arch\E)/,) {
+ tag 'arch-dependent-file-not-in-arch-specific-directory', $file;
+ }
+ }
+
# ELF?
next unless $fileinfo =~ m/^[^,]*\bELF\b/o;
diff --git a/checks/binaries.desc b/checks/binaries.desc
--- a/checks/binaries.desc
+++ b/checks/binaries.desc
@@ -113,6 +113,13 @@
Info: This package installs an ELF binary in the <tt>/usr/share</tt>
hierarchy, which is reserved for architecture-independent files.
+Tag: arch-dependent-file-not-in-arch-specific-directory
+Severity: serious
+Certainty: possible
+Ref: https://wiki.ubuntu.com/MultiarchSpec
+Info: This package is Multi-Arch "same", but it installs an ELF binary in the
+ directory that is not architecture-specific.
+
Tag: binary-in-etc
Severity: serious
Certainty: certain
