Bug#561756: lintian: [new check] Architecture dependent packages without architecture dependent files

[Carl Fürstenberg <azatoth@gmail.com>]

2009/12/26 Russ Allbery <rra@debian.org>:
>
> The hard part about this is that one frequently cannot tell from the file
> type whether it's architecture-dependent.  A great example that frequently
> arises are development headers that include type size information, which
> varies by architecture.  Even the iwatch package actually is
> architecture-dependent since it will only work on Linux, although in that
> case its dependencies take care of that and it's probably safe to make it
> arch: all.
>
> Another case that has come up is a metapackage that needs to be
> architecture-dependent since it has different dependencies on different
> architectures.  The package itself won't contain any
> architecture-dependent files.  I also have a package that contains only
> source code but is architecture-dependent, since what it contains is the
> necessary source for building a kernel module, and it's the stripped
> source that contains only the bits needed for that architecture.
>
> I agree it would be great to have something to check this, but I'm not
> sure how to go about it without a lot of false positives.  Even Perl
> scripts can be architecture-dependent if they use pack to read binary
> data, although they normally aren't.
>
> We may be able to do something experimental or with a very low certainty,
> but it's going to be tricky.

We had some talk on IRC about this, and came to the conclusion that at
the moment there is nothing that says an arch all package should be
used in the first place at all. Also regarding what shouldn't be arch
all package, we could point out that packages like linux-source-2.6.32
is arch all, even though it's filled with arch dependent code. So the
problem could be reduced into following parts: 1: should arch all
packages be used in the first place at all? if yes, then: 2: When
should a package be arch all? and 3: When should a package NOT be arch
all?
The best indication we could see would be "When a binary package can
be used on every architecture, then it should be arch all". Though if
it should be policy or dev ref wasn't resolved (I think it should be
in policy, but others disagree).

But besides policy there might be a way to catch package which are
clearly mislabeled. For example, if a package provides an
non-arch-dependent executable script only, (i.e. perl script in
*/bin"), and no other binary files is distributed (i.e. only text
files under share/etc), then it should be arch all?

-- 
/Carl Fürstenberg <azatoth@gmail.com>