Debian Bug report logs - #693822
Add multiarch metadata

version graph

Package: src:fdupes; Maintainer for src:fdupes is Sandro Tosi <morph@debian.org>;

Reported by: Wookey <wookey@wookware.org>

Date: Tue, 20 Nov 2012 18:18:01 UTC

Severity: normal

Tags: patch

Found in version fdupes/1.50-PR2-4

Fixed in version fdupes/1.51-1

Done: Sandro Tosi <morph@debian.org>

Bug is archived. No further changes may be made.

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to debian-bugs-dist@lists.debian.org, Sandro Tosi <morph@debian.org>:
Bug#693822; Package src:fdupes. (Tue, 20 Nov 2012 18:18:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Wookey <wookey@wookware.org>:
New Bug report received and forwarded. Copy sent to Sandro Tosi <morph@debian.org>. (Tue, 20 Nov 2012 18:18:04 GMT) Full text and rfc822 format available.

Message #5 received at submit@bugs.debian.org (full text, mbox):

From: Wookey <wookey@wookware.org>
To: Debian Bug Tracking System <submit@bugs.debian.org>
Subject: Add multiarch metadata
Date: Tue, 20 Nov 2012 18:15:22 +0000
[Message part 1 (text/plain, inline)]
Source: fdupes
Version: 1.50-PR2-4
Severity: normal
Tags: patch
User: multiarch-devel@lists.alioth.debian.org
Usertag: multiarch

For cross-dependencies to work properly under multiarch this package needs to be marked

Multi-Arch: foreign

so that it can satisfy a build-dependency for any architecture. See http://wiki.debian.org/Multiarch/CrossDependencies and http://wiki.debian.org/Multiarch/Implementation for explanation and background. 

This enable both cross-grading between architectures and cross-building. 


-- System Information:
Debian Release: 6.0.6
  APT prefers stable
  APT policy: (990, 'stable')
Architecture: i386 (i686)

Kernel: Linux 2.6.32.33-kvm-i386-20111128-dirty (SMP w/1 CPU core)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
[fdupes-1.50-PR2-4-multiarch.patch (text/x-diff, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Sandro Tosi <morph@debian.org>:
Bug#693822; Package src:fdupes. (Wed, 16 Jan 2013 23:42:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Sandro Tosi <sandro.tosi@gmail.com>:
Extra info received and forwarded to list. Copy sent to Sandro Tosi <morph@debian.org>. (Wed, 16 Jan 2013 23:42:03 GMT) Full text and rfc822 format available.

Message #10 received at 693822@bugs.debian.org (full text, mbox):

From: Sandro Tosi <sandro.tosi@gmail.com>
To: Wookey <wookey@wookware.org>, 693822@bugs.debian.org
Subject: Re: Bug#693822: Add multiarch metadata
Date: Thu, 17 Jan 2013 00:38:41 +0100
Hello,

On Tue, Nov 20, 2012 at 7:15 PM, Wookey <wookey@wookware.org> wrote:
> For cross-dependencies to work properly under multiarch this package needs to be marked
>
> Multi-Arch: foreign
>
> so that it can satisfy a build-dependency for any architecture. See http://wiki.debian.org/Multiarch/CrossDependencies and http://wiki.debian.org/Multiarch/Implementation for explanation and background.

thanks for forcing me to read those docs to understand what this bug
is about.. From "When shouldn't I add M-A: foreign?" I can see that I
don't have to set it for arch: any package, such as fdupes - so what's
this all about?

Additionally, if fixing apt would have avoided to file several bugs,
then probably you'd have to pursue that road.

Cheers,
--
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi



Information forwarded to debian-bugs-dist@lists.debian.org, Sandro Tosi <morph@debian.org>:
Bug#693822; Package src:fdupes. (Thu, 17 Jan 2013 04:15:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Wookey <wookey@wookware.org>:
Extra info received and forwarded to list. Copy sent to Sandro Tosi <morph@debian.org>. (Thu, 17 Jan 2013 04:15:03 GMT) Full text and rfc822 format available.

Message #15 received at 693822@bugs.debian.org (full text, mbox):

From: Wookey <wookey@wookware.org>
To: Sandro Tosi <sandro.tosi@gmail.com>
Cc: 693822@bugs.debian.org
Subject: Re: Bug#693822: Add multiarch metadata
Date: Thu, 17 Jan 2013 04:13:36 +0000
+++ Sandro Tosi [2013-01-17 00:38 +0100]:
> Hello,
> 
> On Tue, Nov 20, 2012 at 7:15 PM, Wookey <wookey@wookware.org> wrote:
> > For cross-dependencies to work properly under multiarch this package needs to be marked
> >
> > Multi-Arch: foreign
> >
> > so that it can satisfy a build-dependency for any architecture. See http://wiki.debian.org/Multiarch/CrossDependencies and http://wiki.debian.org/Multiarch/Implementation for explanation and background.
> 
> thanks for forcing me to read those docs to understand what this bug
> is about.. From "When shouldn't I add M-A: foreign?" I can see that I
> don't have to set it for arch: any package, such as fdupes - so what's
> this all about?

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. 

If you could explain why you misunderstood the "When shouldn't I add
M-A: foreign?", I'll try and improve the wording. 

Wookey
-- 
Principal hats:  Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/



Information forwarded to debian-bugs-dist@lists.debian.org:
Bug#693822; Package src:fdupes. (Thu, 24 Jan 2013 19:12:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Sandro Tosi <morph@debian.org>:
Extra info received and forwarded to list. (Thu, 24 Jan 2013 19:12:06 GMT) Full text and rfc822 format available.

Message #20 received at 693822@bugs.debian.org (full text, mbox):

From: Sandro Tosi <morph@debian.org>
To: Wookey <wookey@wookware.org>
Cc: 693822@bugs.debian.org
Subject: Re: Bug#693822: Add multiarch metadata
Date: Thu, 24 Jan 2013 20:09:25 +0100
On Thu, Jan 17, 2013 at 5:13 AM, Wookey <wookey@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.

> 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.

--
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi



Information forwarded to debian-bugs-dist@lists.debian.org, Sandro Tosi <morph@debian.org>:
Bug#693822; Package src:fdupes. (Thu, 07 Feb 2013 11:30:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Colin Watson <cjwatson@debian.org>:
Extra info received and forwarded to list. Copy sent to Sandro Tosi <morph@debian.org>. (Thu, 07 Feb 2013 11:30:03 GMT) Full text and rfc822 format available.

Message #25 received at 693822@bugs.debian.org (full text, mbox):

From: Colin Watson <cjwatson@debian.org>
To: Sandro Tosi <morph@debian.org>, 693822@bugs.debian.org
Cc: Wookey <wookey@wookware.org>
Subject: Re: Bug#693822: Add multiarch metadata
Date: Thu, 7 Feb 2013 11:27:55 +0000
[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 <wookey@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                                       [cjwatson@debian.org]



Information forwarded to debian-bugs-dist@lists.debian.org, Sandro Tosi <morph@debian.org>:
Bug#693822; Package src:fdupes. (Fri, 08 Feb 2013 11:54:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to clarcky297@gmail.com:
Extra info received and forwarded to list. Copy sent to Sandro Tosi <morph@debian.org>. (Fri, 08 Feb 2013 11:54:03 GMT) Full text and rfc822 format available.

Message #30 received at 693822@bugs.debian.org (full text, mbox):

From: clarcky297@gmail.com
To: linux.debian.bugs.dist@googlegroups.com
Cc: Colin Watson <cjwatson@debian.org>, 693822@bugs.debian.org
Subject: Re: Bug#693822: Add multiarch metadata
Date: Fri, 8 Feb 2013 03:51:48 -0800 (PST)
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 <wookey@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
> 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                                       [cjwatson@debian.org]
> 
> 
> 
> 
> 
> -- 
> 
> To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@lists.debian.org
> 
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org




Added tag(s) pending. Request was from Sandro Tosi <morph@debian.org> to control@bugs.debian.org. (Sun, 19 Jan 2014 23:27:05 GMT) Full text and rfc822 format available.

Reply sent to Sandro Tosi <morph@debian.org>:
You have taken responsibility. (Wed, 22 Jan 2014 22:51:05 GMT) Full text and rfc822 format available.

Notification sent to Wookey <wookey@wookware.org>:
Bug acknowledged by developer. (Wed, 22 Jan 2014 22:51:05 GMT) Full text and rfc822 format available.

Message #37 received at 693822-close@bugs.debian.org (full text, mbox):

From: Sandro Tosi <morph@debian.org>
To: 693822-close@bugs.debian.org
Subject: Bug#693822: fixed in fdupes 1.51-1
Date: Wed, 22 Jan 2014 22:48:58 +0000
Source: fdupes
Source-Version: 1.51-1

We believe that the bug you reported is fixed in the latest version of
fdupes, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 693822@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Sandro Tosi <morph@debian.org> (supplier of updated fdupes package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.8
Date: Wed, 22 Jan 2014 23:40:39 +0100
Source: fdupes
Binary: fdupes
Architecture: source amd64
Version: 1.51-1
Distribution: unstable
Urgency: medium
Maintainer: Sandro Tosi <morph@debian.org>
Changed-By: Sandro Tosi <morph@debian.org>
Description: 
 fdupes     - identifies duplicate files within given directories
Closes: 693822 719246
Changes: 
 fdupes (1.51-1) unstable; urgency=medium
 .
   * New upstream release
   * debian/watch
     - point to Google Code
   * debian/patches/*
     - removed patches applied upstream
   * debian/control
     - bump Standards-Version to 3.9.5 (no changes needed)
     - use canonical URL for Alioth
     - add Multiarch metadata to allow cross build-dependencies; thanks to Wookey
       for the report and patch; Closes: #693822
   * debian/rules
     - migrated to dh sequencer
   * debian/{rules, patches/80-bts719246-set-CC-to-allow-cross-compilation.patch}
     - allow to pass the CC compiler to allow for cross-compilation; thanks to
       Eleanor Chen for the report and patch; Closes: #719246
Checksums-Sha1: 
 f817e58f273ce586163c76641bd9c5ffef8544ea 1161 fdupes_1.51-1.dsc
 8276b39026f57a2f9503d7af18efca0a7d42b8ec 48942 fdupes_1.51.orig.tar.gz
 ce8ca4a7afc3ababc87d5ca75daa5d56bc128431 8756 fdupes_1.51-1.debian.tar.xz
 aa4d32d5a36b15c9385071898dc866d4028d3728 18864 fdupes_1.51-1_amd64.deb
Checksums-Sha256: 
 a7b10c492685d410bf47cd1370a9c11bf7f4c82c0c5ef5aa3a4cefe4300d4470 1161 fdupes_1.51-1.dsc
 87dbc85b7b9cdb9626e713dd8078bd7487bceb58d47ceaff5404a9e6fd062881 48942 fdupes_1.51.orig.tar.gz
 4c341c4dac7075af51b7f68609d03711e55eda82d6855f6f4e026271bb0b82bb 8756 fdupes_1.51-1.debian.tar.xz
 1fbe05d0395b9ccfac9722e099e00e3d20a998d996848030ad42d01a39236180 18864 fdupes_1.51-1_amd64.deb
Files: 
 3725c11248403e4d94e59540f4e818ff 1161 utils optional fdupes_1.51-1.dsc
 47d0410c90c9e51e450933ba35a32b62 48942 utils optional fdupes_1.51.orig.tar.gz
 edbfd9bcf15e34b341c2e082e61201cc 8756 utils optional fdupes_1.51-1.debian.tar.xz
 be1bd7f5cf28f3d0b8363cbc95de8be1 18864 utils optional fdupes_1.51-1_amd64.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)

iEYEARECAAYFAlLgSWUACgkQAukwV0RN2VDTWQCfTdL2v6dYvRlIIiX4fHgrIfRc
jfgAni95K1cdzVJMF+6dOX2L3qwz+XKR
=teFk
-----END PGP SIGNATURE-----




Bug archived. Request was from Debbugs Internal Request <owner@bugs.debian.org> to internal_control@bugs.debian.org. (Tue, 25 Feb 2014 07:27:36 GMT) Full text and rfc822 format available.

Send a report that this bug log contains spam.


Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Thu Apr 17 11:18:31 2014; Machine Name: beach.debian.org

Debian Bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.