2009/12/26 Russ Allbery <r...@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 <azat...@gmail.com> -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
