On Thursday, February 7, 2013 5:10:01 PM UTC+5:30, Colin Watson wrote: > [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 <[email protected]> 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 > http://ww.ashisoft.com > > > 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 [[email protected]] > > > > > > -- > > To UNSUBSCRIBE, email to [email protected] > > with a subject of "unsubscribe". Trouble? Contact [email protected]
-- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
