[I didn't write the wiki page in question here, but perhaps I can help
to clarify it.]
On Thu, Jan 24, 2013 at 08:09:25PM +0100, Sandro Tosi wrote:
> On Thu, Jan 17, 2013 at 5:13 AM, Wookey <woo...@wookware.org> wrote:
> > That's not what that paragraph says. Sorry if it's confusing. You
> > shouldn't add M-A: foreign if the package isn't arch-independent in
> > it's _effects_ (i.e you should set M-A: foreign if the package's
> > _effect_ is arch-independent). Whether the package itself is arch :any
> > or not is not relevent. So fdupes will find duplicate files just the
> > same if you run the arm version or the sparc version or the i386
> > version. That makes it M-A: foreign.
>
> I don't get why it wouldn't find duplicate files. The same I don't get
> why it would need to add that, in particular because you skipped the
> part about apt solution, would would avoid to "fix" (?) several
> packages.
The bit in that page about apt is not relevant to fdupes anyway, since
fdupes is Architecture: any, not all.
Here's the deal given apt's current behaviour (I'm simplifying a bit to
avoid boredom, but this at least covers any/all and foreign/not):
1) Architecture: any, not M-A: foreign
These packages contain architecture-dependent code, and also have
architecture-dependent effects: that is, you need to pick the build
of the package for the correct architecture.
For example, libraries are generally like this, as are some tools
that only operate on objects of the same architecture (say,
binutils). This is a safe conservative default for Architecture:
any packages, since it's how all such packages worked before
multiarch came along.
2) Architecture: any, M-A: foreign
These packages contain architecture-dependent code, but it really
doesn't matter which architecture you get as long as you can execute
the binaries.
Many simple tools are like this, although we can't safely assume
that any given tool will be like this without being told; failing to
cross-build something because we can't satisfy its
cross-build-dependencies is better than cross-building it
incorrectly, and likewise for run-time uses of multiarch.
3) Architecture: all, not M-A: foreign
These packages contain architecture-independent code, but they may
only satisfy dependencies of packages of the primary architecture or
of other packages that are also Architecture: all. The reason for
this restrictions is to avoid breaking pre-multiarch assumptions of
packages that depend on Architecture: all packages and assume that
*their* (transitive) dependencies will be resolved using the native
architecture.
A package that contained an architecture-independent tool but that
also depended on libfoo-dev might be in this category.
4) Architecture: all, M-A: foreign
These packages contain architecture-independent code, and they may
satisfy dependencies of packages of any architecture. Most
architecture-independent packages fall into this category.
Steve's proposal in #666772 is to say that we don't need to be
ultra-conservative for cross-build-dep handling, and for that purpose we
can treat 3) like 4). Based on my experience with cross-building, I
tend to agree that that makes sense - but it doesn't have any effect on
this bug either way.
It would not make sense to extend #666772 to Architecture: any packages,
because very many of those *do* have architecture-dependent effects; all
that this would achieve would be having to add a roughly similar number
of Multi-Arch: tags to packages in the other direction.
> > If you could explain why you misunderstood the "When shouldn't I add
> > M-A: foreign?", I'll try and improve the wording.
>
> Well, if you start a paragraph saying "When the package is not
> arch-independent" that means to me it's arch:any, short-cut, that
> package is not requires a M-A: foreign.
The full sentence you're quoting is:
When the package is not arch-independent in its effects, i.e if you
run the wrong-arch version it will operate on the wrong files or
produce the wrong output.
The "in its effects" matters here. That is, binutils is
architecture-dependent in its effects, because (for example) the armhf
version of nm operates only on armhf objects while the i386 version of
nm operates only on i386 objects; but the effects of fdupes are
architecture-independent, even though it happens to be a compiled
executable.
Architecture: any packages are precisely those which are rather evenly
divided between those where the architecture you get matters and those
where it doesn't. A substantial number of them have already correctly
had Multi-Arch: foreign added to them, and fdupes should too.
Does this help?
--
Colin Watson [cjwat...@debian.org]
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
