Debian Bug report logs - #646288
apt-get build-dep -a $arch: wrong tradeoff for the default?

version graph

Package: apt; Maintainer for apt is APT Development Team <deity@lists.debian.org>; Source for apt is src:apt.

Reported by: Steve Langasek <vorlon@debian.org>

Date: Sat, 22 Oct 2011 22:00:11 UTC

Severity: wishlist

Tags: patch

Found in version apt/0.8.16~exp5

Fixed in version apt/0.8.16~exp13

Done: Michael Vogt <mvo@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, debian-embedded@lists.debian.org, multiarch-devel@lists.alioth.debian.org, APT Development Team <deity@lists.debian.org>:
Bug#646288; Package apt. (Sat, 22 Oct 2011 22:00:14 GMT) Full text and rfc822 format available.

Acknowledgement sent to Steve Langasek <vorlon@debian.org>:
New Bug report received and forwarded. Copy sent to debian-embedded@lists.debian.org, multiarch-devel@lists.alioth.debian.org, APT Development Team <deity@lists.debian.org>. (Sat, 22 Oct 2011 22:00:14 GMT) Full text and rfc822 format available.

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

From: Steve Langasek <vorlon@debian.org>
To: submit@bugs.debian.org
Subject: apt-get build-dep -a $arch: wrong tradeoff for the default?
Date: Sat, 22 Oct 2011 14:58:01 -0700
[Message part 1 (text/plain, inline)]
Package: apt
Version: 0.8.16~exp5
Severity: wishlist
User: multiarch-devel@lists.alioth.debian.org
Usertags: multiarch

I've been having lots of fun playing with the 'apt-get build-dep -a $arch'
support added to apt in version 0.8.15.3 (fixing bug #632221).  As I do so,
however, I think we've made a wrong trade-off in terms of the default
behavior for packages.  I've actually thought this for a while, but it's
become enough of a hassle now that I think I need to raise it as a bug and
agitate for getting the behavior changed. :)

apt accurately implements the behavior requested on
<https://wiki.ubuntu.com/MultiarchCross>, which says that for a package
which is Multi-Arch: no, the build-dependency will be satisfied using the
package for the build architecture.  The rationale for this is that, whereas
library -dev packages are likely to be touched anyway in order to make them
Multi-Arch: same, the random other non-library packages that are used as
build dependencies would not otherwise be updated to be marked Multi-Arch:
foreign, so by defaulting to the build-arch packages we can focus on just
getting the -dev packages marked Multi-Arch: same.

This is correct as far as it goes, but there are a number of complications.

 - Unlike marking a package Multi-Arch: foreign, which is just adding
   metadata, converting a -dev package to be Multi-Arch: same is not always
   easy.  There are no best practice guidelines yet for converting a -dev
   package to be Multi-Arch: same when it contains a mix of
   architecture-dependent and architecture-independent headers, so many of
   these -dev packages are not getting converted right now.  Of 696 packages
   that have been tagged Multi-Arch: same in unstable[1], only 74 of them
   are -dev packages.  Since some of the affected packages are pretty low in
   the dependency tree, this effectively stops us from reaching critical
   mass of cross-build-friendly multiarch -dev packages.

 - Whereas cross-installability of -dev packages is a must for
   cross-building, for the vast majority of libraries, *co*installability is
   merely a nice to have.  There are very few libraries that you need to
   build against both the host and build versions of as part of a single
   package build; so while it's inconvenient to have to swap -dev packages
   out in a build environment when switching target architectures, it's
   tolerable... especially since it would enable uses that aren't possible
   today.  Only the apt implementation makes M-A: same a requirement.

 - There are a lot more library -dev packages as build-dependencies than
   there are non-dev packages as build-dependencies, at least for the cases
   that are interesting for cross-compilation.  If we ignore
   build-dependencies on python, java, ruby, perl, gir, haskell, and erlang
   packages[3], approximately[4] 60% of all build-dependencies are on
   library -dev packages; and of the ones that are not -dev packages, there
   are already more Multi-Arch tags set in the archive (91) than there are
   on the -dev packages[5]!  This implies to me that many of these packages
   will be marked Multi-Arch: foreign anyway because the tag is needed for
   runtime.

So for the above reasons I think it would be better for apt-get build-dep to
require the DEB_HOST_ARCH package for M-A: no build-depends.

Cc:ed to multiarch-devel and debian-embedded for comments.  Since this
proposal implies pushing more patches to packages to make them Multi-Arch:
foreign, perhaps this should be discussed on debian-devel to get a consensus
there?

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org

[1] grep-dctrl  -FMulti-Arch same /var/lib/apt/lists/_mirror_dists_sid_main_binary-amd64_Packages \
    | grep -c Package
[2] grep-dctrl  -FMulti-Arch same /var/lib/apt/lists/_mirror_dists_sid_main_binary-amd64_Packages \
    | grep -c Package.*-dev
[3] grep-dctrl -sBuild-Depends -r '.' -n /var/lib/apt/lists/debian.osuosl.org_debian_dists_sid_main_source_Sources \
    | sed -e's/([^)]\+)//g; s/\[[^]]\+\]//g; s/[,|]//g; s/ \+/\n/g' | sort -u \
    | grep -vE 'python|java|ruby|-perl|^gir|^libghc|haskell|erlang'
[4] "approximately" - because included in this count are some packages like
    x11proto-dev packages, which are Arch: all (and Multi-Arch: foreign),
    and a few packages like autotools-dev which aren't headers/libs at all
[5] grep-dctrl -sBuild-Depends -r '.' -n /var/lib/apt/lists/debian.osuosl.org_debian_dists_sid_main_source_Sources \
    | sed -e's/([^)]\+)//g; s/\[[^]]\+\]//g; s/[,|]//g; s/ \+/\n/g' | sort -u \
    | grep -vE 'python|java|ruby|-perl|^gir|^libghc|haskell|erlang' \
    | grep -v -- -dev | xargs apt-cache show |grep -c Multi-Arch

[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, APT Development Team <deity@lists.debian.org>:
Bug#646288; Package apt. (Sun, 23 Oct 2011 07:15:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Debian Embedded <debian-embedded@lists.debian.org>:
Extra info received and forwarded to list. Copy sent to APT Development Team <deity@lists.debian.org>. (Sun, 23 Oct 2011 07:15:05 GMT) Full text and rfc822 format available.

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

From: Neil Williams <codehelp@debian.org>
To: Debian Embedded <debian-embedded@lists.debian.org>
Cc: vorlon@debian.org, 646288@bugs.debian.org
Subject: Re: Bug#646288: apt-get build-dep -a $arch: wrong tradeoff for the default?
Date: Sun, 23 Oct 2011 08:11:25 +0100
[Message part 1 (text/plain, inline)]
On Sat, 22 Oct 2011 14:58:01 -0700
Steve Langasek <vorlon@debian.org> wrote:

> I've been having lots of fun playing with the 'apt-get build-dep -a $arch'
> support added to apt in version 0.8.15.3 (fixing bug #632221).  As I do so,
> however, I think we've made a wrong trade-off in terms of the default
> behavior for packages.  I've actually thought this for a while, but it's
> become enough of a hassle now that I think I need to raise it as a bug and
> agitate for getting the behavior changed. :)

IIRC the reasoning for the original default was to provide
cross-building behaviour post-Multiarch which was the most similar to
cross-building behaviour under dpkg-cross, with the fundamental change
that the cross-dependencies in Multiarch world would be understood by
apt and dpkg.

Logically, I still think this should be the long term goal. What I
think we're covering here is the interim stages whilst there is this
lack of clear direction on the behaviour of -dev packages in Multiarch
and a lack of -dev packages with appropriate changes.

If we can get packages to work with the long term goal it would make it
easier to achieve the goal without having to make the changes twice.

> apt accurately implements the behavior requested on
> <https://wiki.ubuntu.com/MultiarchCross>, which says that for a package
> 
> This is correct as far as it goes, but there are a number of complications.
> 
>  - Unlike marking a package Multi-Arch: foreign, which is just adding
>    metadata, converting a -dev package to be Multi-Arch: same is not always
>    easy.  There are no best practice guidelines yet for converting a -dev
>    package to be Multi-Arch: same when it contains a mix of
>    architecture-dependent and architecture-independent headers, so many of
>    these -dev packages are not getting converted right now.  Of 696 packages
>    that have been tagged Multi-Arch: same in unstable[1], only 74 of them
>    are -dev packages.  Since some of the affected packages are pretty low in
>    the dependency tree, this effectively stops us from reaching critical
>    mass of cross-build-friendly multiarch -dev packages.

Exactly - so in the interim period where there are no clear guidelines
yet and no critical mass, do we actually need to change the default or
just accept the *result* of these complications?

>  - Whereas cross-installability of -dev packages is a must for
>    cross-building, for the vast majority of libraries, *co*installability is
>    merely a nice to have.  There are very few libraries that you need to
>    build against both the host and build versions of as part of a single
>    package build; so while it's inconvenient to have to swap -dev packages
>    out in a build environment when switching target architectures, it's
>    tolerable... especially since it would enable uses that aren't possible
>    today.  Only the apt implementation makes M-A: same a requirement.

The result being, of course, that swapping -dev packages in and out of
the build environment is simply not going to happen (because people
will generally need to be able to make a bug fix natively, cross-build
it quickly and get back to development). Instead "swapping -dev
packages in and out of the build environment" simply translates into
"requiring cross-builds to happen in chroots" like pbuilder, schroot
etc.

I think we can specify that without needing to change the default
behaviour. Are there reasons why this wouldn't work? Effectively we
don't hot-swap build-deps, we just have two build environments.

The packages which caused trouble with this in Lenny were GTK and pango
which both build native tools which are executed during the build to
generate package metadata which is used by the cross-built binaries.
There was always a problem here about potentially getting the wrong
data because the work was done on the wrong arch and potentially in the
wrong directories (due to dpkg-cross). Those problems are fixable but
*will* require the build-dependencies of the native tools to be present
in the same build environment and at precisely the same time.
libglib2.0-dev is one of the most likely here.

>  - There are a lot more library -dev packages as build-dependencies than
>    there are non-dev packages as build-dependencies, at least for the cases
>    that are interesting for cross-compilation.  If we ignore
>    build-dependencies on python, java, ruby, perl, gir, haskell, and erlang
>    packages[3], approximately[4] 60% of all build-dependencies are on
>    library -dev packages; and of the ones that are not -dev packages, there
>    are already more Multi-Arch tags set in the archive (91) than there are
>    on the -dev packages[5]!  This implies to me that many of these packages
>    will be marked Multi-Arch: foreign anyway because the tag is needed for
>    runtime.

It was always excluding the non-dev dependencies like debhelper and
native build dependencies like cmake|automake etc. which caused all the
problems with the apt-cross|dpkg-cross partnership. As long as that is
working in a way that allows apt to automatically manage upgrades to
existing packages (of both architectures), we all win.

Upgradability of cross -dev packages is the single biggest gain I need
from Multiarch. Proper cross-architecture installation dependency
resolution and management. I don't really care if I can't have -dev
packages for armel and amd64 in the same build environment initially -
as long as that can happen eventually. What I need is for armel build
dependency packages to be automatically and easily upgradable in-situ,
using apt itself, without the need for secondary tools like apt-cross,
xapt etc.

i.e. apt-get build-dep -a $arch isn't actually that much of a gain - we
can do that without MultiArch being complete.

apt-get update -a $arch ;; apt-get dist-upgrade -a $arch is FAR more
useful because it is something which has been impossible with
dpkg-cross. It worked for small values of "worked" with apt-cross and
it just doesn't work at all nicely with xapt.

> So for the above reasons I think it would be better for apt-get build-dep to
> require the DEB_HOST_ARCH package for M-A: no build-depends.

If we accept that switching -dev packages in and out of a build
environment just makes cross-building unnecessarily painful for actual
cross architecture development (rather than cross-arch distro
preparation) then we have to mandate that until the guidelines for -dev
packages are more achievable, that cross-building in MultiArch world is
restricted to chroots. If that is accepted, then it doesn't need a
change in apt - the chroot can use DEB_BUILD_ARCH in the chroot as
easily as it can use DEB_HOST_ARCH, just without needing a change to
the default.

What have I missed?
 
> Cc:ed to multiarch-devel and debian-embedded for comments.  Since this
> proposal implies pushing more patches to packages to make them Multi-Arch:
> foreign, perhaps this should be discussed on debian-devel to get a consensus
> there?

If we mandate chroots, until critical mass is achieved, would we still
need changes?

(I must be missing something somewhere ....)

-- 


Neil Williams
=============
http://www.linux.codehelp.co.uk/

[Message part 2 (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, APT Development Team <deity@lists.debian.org>:
Bug#646288; Package apt. (Sun, 06 Nov 2011 23:12:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Steve Langasek <vorlon@debian.org>:
Extra info received and forwarded to list. Copy sent to APT Development Team <deity@lists.debian.org>. (Sun, 06 Nov 2011 23:12:06 GMT) Full text and rfc822 format available.

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

From: Steve Langasek <vorlon@debian.org>
To: Debian Embedded <debian-embedded@lists.debian.org>
Cc: 646288@bugs.debian.org
Subject: Re: Bug#646288: apt-get build-dep -a $arch: wrong tradeoff for the default?
Date: Sun, 6 Nov 2011 15:08:45 -0800
[Message part 1 (text/plain, inline)]
Hi Neil,

On Sun, Oct 23, 2011 at 08:11:25AM +0100, Neil Williams wrote:
> On Sat, 22 Oct 2011 14:58:01 -0700
> Steve Langasek <vorlon@debian.org> wrote:

> > I've been having lots of fun playing with the 'apt-get build-dep -a $arch'
> > support added to apt in version 0.8.15.3 (fixing bug #632221).  As I do so,
> > however, I think we've made a wrong trade-off in terms of the default
> > behavior for packages.  I've actually thought this for a while, but it's
> > become enough of a hassle now that I think I need to raise it as a bug and
> > agitate for getting the behavior changed. :)

> IIRC the reasoning for the original default was to provide
> cross-building behaviour post-Multiarch which was the most similar to
> cross-building behaviour under dpkg-cross, with the fundamental change
> that the cross-dependencies in Multiarch world would be understood by
> apt and dpkg.

> Logically, I still think this should be the long term goal. What I
> think we're covering here is the interim stages whilst there is this
> lack of clear direction on the behaviour of -dev packages in Multiarch
> and a lack of -dev packages with appropriate changes.

> If we can get packages to work with the long term goal it would make it
> easier to achieve the goal without having to make the changes twice.

I think there are three long-term goals here:

 - that it be clear from any build-dep line which version of a package is
   needed / will be installed when cross building
 - that it be possible to express *any* combination of needed native/foreign
   build-dependencies in debian/control, and that these be actually
   installable for any package in the archive
 - that all the work done around this be integrated into the official Debian
   archive, and not carried as a delta.

Now, I think it's worth pointing out that the M-A: foreign metadata I'm
proposing to add in support of flipping the apt-get build-dep default is
*not* incorrect: it is entirely accurate to say that these packages satisfy
foreign-architecture dependencies and build-dependencies, it's just that we
wouldn't have bothered to annotate many of these if they were only used as
build-dependencies.  Conversely, it's not incorrect to convert all the
-dev packages so that they're coinstallable and mark them Multi-Arch: same.

It's just that one of these things can be achieved much more quickly and
with less developer effort, allowing us to begin reaping the benefits of
multiarch for cross-building immediately provided that we flip one of the
defaults in the spec.


>>  - Unlike marking a package Multi-Arch: foreign, which is just adding
>>    metadata, converting a -dev package to be Multi-Arch: same is not
>>    always easy.  There are no best practice guidelines yet for converting
>>    a -dev package to be Multi-Arch: same when it contains a mix of
>>    architecture-dependent and architecture-independent headers, so many
>>    of these -dev packages are not getting converted right now.  Of 696
>>    packages that have been tagged Multi-Arch: same in unstable[1], only
>>    74 of them are -dev packages.  Since some of the affected packages are
>>    pretty low in the dependency tree, this effectively stops us from
>>    reaching critical mass of cross-build-friendly multiarch -dev
>>    packages.

> Exactly - so in the interim period where there are no clear guidelines
> yet and no critical mass, do we actually need to change the default or
> just accept the *result* of these complications?

So we had a couple of sessions at UDS/Linaro Connect this past week where
this issue was discussed with the apt developers and with folks interested
in ARM cross-compiling.  I really ought to have invited you to follow the
sessions remotely, but it slipped my mind in all the pre-conference
planning.  I apologize!  You can read the session agendas and "minutes"
here:

  https://blueprints.launchpad.net/ubuntu/+spec/ubuntu-arm-p-cross-compilable-packages
  http://summit.ubuntu.com/uds-p/meeting/19538/ubuntu-arm-p-cross-compilable-packages/

  https://blueprints.launchpad.net/linaro-ubuntu/+spec/linaro-platforms-lc4.11-multiarch-crossbuilding
  http://summit.ubuntu.com/uds-p/meeting/19823/linaro-platforms-lc4.11-multiarch-crossbuilding/

There was a very strong consensus among those present that we would target
multiarch-based auto-cross-building of the relevant packages for the Ubuntu
Precise cycle (April 2012 release).  So one way or the other, there will be
a core set of cross-buildable packages available by then.  But I don't know
if it will be a /critical mass/ if we have to stop to convert every -dev
package along the way, vs. letting this conversion continue to happen in
parallel.

There was also a consensus that defaulting to DEB_HOST_ARCH for M-A: no
build-dependencies is the better route, because it lets us get farther up
the stack much quicker.  This doesn't preclude getting -dev packages made
M-A: same (indeed, I just filed bug #647855 for libattr1-dev), it just means
a different short-term focus.

>>  - Whereas cross-installability of -dev packages is a must for
>>    cross-building, for the vast majority of libraries,
>>    *co*installability is merely a nice to have.  There are very few
>>    libraries that you need to build against both the host and build
>>    versions of as part of a single package build; so while it's
>>    inconvenient to have to swap -dev packages out in a build environment
>>    when switching target architectures, it's tolerable...  especially
>>    since it would enable uses that aren't possible today.  Only the apt
>>    implementation makes M-A: same a requirement.

> The result being, of course, that swapping -dev packages in and out of
> the build environment is simply not going to happen (because people
> will generally need to be able to make a bug fix natively, cross-build
> it quickly and get back to development). Instead "swapping -dev
> packages in and out of the build environment" simply translates into
> "requiring cross-builds to happen in chroots" like pbuilder, schroot
> etc.

> I think we can specify that without needing to change the default
> behaviour. Are there reasons why this wouldn't work? Effectively we
> don't hot-swap build-deps, we just have two build environments.

That's an interesting take on it that doesn't really resemble my own
development process these days.  I do all of my development and test-builds
in a chroot; and because chroots are cheap (especially with schroot+LVM
snapshotting), if I need to fire up a separate native chroot next to the one
I'm using for cross-building, I can easily do so.  And I have a local mirror
for the things I'm working on.  I guess you're doing something else that
makes swapping -dev packages more expensive in your development environment?

I think that's one reason among many why we want to make -dev packages
co-installable.  My only concern is with decoupling this problem from the
problem of being able to auto-cross-build in a pristine environment.

> The packages which caused trouble with this in Lenny were GTK and pango
> which both build native tools which are executed during the build to
> generate package metadata which is used by the cross-built binaries.
> There was always a problem here about potentially getting the wrong
> data because the work was done on the wrong arch and potentially in the
> wrong directories (due to dpkg-cross). Those problems are fixable but
> *will* require the build-dependencies of the native tools to be present
> in the same build environment and at precisely the same time.
> libglib2.0-dev is one of the most likely here.

No disagreement!  There are a number of -dev packages whose conversion to
M-A: same is critical path.  I just want to separate these out from the ones
that don't need to be.

> Upgradability of cross -dev packages is the single biggest gain I need
> from Multiarch. Proper cross-architecture installation dependency
> resolution and management. I don't really care if I can't have -dev
> packages for armel and amd64 in the same build environment initially -
> as long as that can happen eventually. What I need is for armel build
> dependency packages to be automatically and easily upgradable in-situ,
> using apt itself, without the need for secondary tools like apt-cross,
> xapt etc.

Yep, and you definitely get that whether or not a given -dev package is
coinstallable.

> i.e. apt-get build-dep -a $arch isn't actually that much of a gain - we
> can do that without MultiArch being complete.

I think it's a *huge* gain to have the standard tools do the right thing for
cross builds.  Among other things, it facilitates setting up
cross-autobuilders.

If you consider apt-get build-dep -a $arch not a big gain, does that mean
you don't mind changes to its behavior as long as it doesn't get in the way
of the other things you're working on?

BTW, there's another benefit to changing the interpretation of M-A: no
build-deps: it brings it into line with the interpretation of M-A: no in
Depends, which means that tools like mk-build-deps, which converts a
Build-Depends: line into a Depends: line, can also work in a cross-building
context.  (cf. bug #647745.)  Currently, apt-get build-dep gives an opposite
interpretation, making it impossible to sensibly map these.

> If we accept that switching -dev packages in and out of a build
> environment just makes cross-building unnecessarily painful for actual
> cross architecture development (rather than cross-arch distro
> preparation) then we have to mandate that until the guidelines for -dev
> packages are more achievable, that cross-building in MultiArch world is
> restricted to chroots. If that is accepted, then it doesn't need a
> change in apt - the chroot can use DEB_BUILD_ARCH in the chroot as
> easily as it can use DEB_HOST_ARCH, just without needing a change to
> the default.

I'm not sure what you're arguing here.  Are you advocating a fully emulated
chroot?  That would be significantly less useful than a proper cross-chroot.

Again, my goal is to help get a quicker payoff from these changes, because
that will encourage more people to work on this in parallel.  If you're not
using apt-get build-dep -a $arch anyway, then changing its behavior doesn't
seem to cost you anything... but it does immediately benefit anyone trying
to do automatic or (semi-automatic) cross-builds of packages.  *That* is
what will enable us to reach critical mass most quickly.

> > Cc:ed to multiarch-devel and debian-embedded for comments.  Since this
> > proposal implies pushing more patches to packages to make them Multi-Arch:
> > foreign, perhaps this should be discussed on debian-devel to get a consensus
> > there?

> If we mandate chroots, until critical mass is achieved, would we still
> need changes?

If you mean fully-emulated chroots, that's not something that can be
mandated.  Various people working in this space have need of cross-build
environments (chrooted or otherwise).

If you mean cross-build chroots, then yes, this change is absolutely still
relevant.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, APT Development Team <deity@lists.debian.org>:
Bug#646288; Package apt. (Mon, 07 Nov 2011 01:12:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Steve Langasek <vorlon@debian.org>:
Extra info received and forwarded to list. Copy sent to APT Development Team <deity@lists.debian.org>. (Mon, 07 Nov 2011 01:12:03 GMT) Full text and rfc822 format available.

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

From: Steve Langasek <vorlon@debian.org>
To: 646288@bugs.debian.org
Cc: debian-embedded@lists.debian.org
Subject: Re: apt-get build-dep -a $arch: wrong tradeoff for the default?
Date: Sun, 6 Nov 2011 17:09:02 -0800
[Message part 1 (text/plain, inline)]
Attached is a patch that mostly works for this, except that Architecture:
all, Multi-Arch: no packages are regarded as satisfying build-dependencies
when they probably shouldn't.

Comments welcome.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org
[apt-646288.patch (text/x-diff, attachment)]
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, APT Development Team <deity@lists.debian.org>:
Bug#646288; Package apt. (Mon, 07 Nov 2011 01:24:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Steve Langasek <vorlon@debian.org>:
Extra info received and forwarded to list. Copy sent to APT Development Team <deity@lists.debian.org>. (Mon, 07 Nov 2011 01:24:03 GMT) Full text and rfc822 format available.

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

From: Steve Langasek <vorlon@debian.org>
To: 646288@bugs.debian.org, debian-embedded@lists.debian.org
Subject: Re: apt-get build-dep -a $arch: wrong tradeoff for the default?
Date: Sun, 6 Nov 2011 17:20:25 -0800
[Message part 1 (text/plain, inline)]
On Sun, Nov 06, 2011 at 05:09:02PM -0800, Steve Langasek wrote:
> Attached is a patch that mostly works for this, except that Architecture:
> all, Multi-Arch: no packages are regarded as satisfying build-dependencies
> when they probably shouldn't.

> Comments welcome.

Bah, cut'n'waste error.  Fixed patch attached.

Note that there also seems to have been an error in the handling of M-A:
same build-dependencies, which should be fixed in any case here; an
un-decorated build-dependency on a M-A: same package was apparently being
resolved to the build architecture, and it definitely needs to be resolved
to the host architecture.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org
[apt-646288.patch (text/x-diff, attachment)]
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, APT Development Team <deity@lists.debian.org>:
Bug#646288; Package apt. (Sat, 28 Jan 2012 22:18:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Steve Langasek <vorlon@debian.org>:
Extra info received and forwarded to list. Copy sent to APT Development Team <deity@lists.debian.org>. (Sat, 28 Jan 2012 22:18:04 GMT) Full text and rfc822 format available.

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

From: Steve Langasek <vorlon@debian.org>
To: 646288@bugs.debian.org
Subject: Re: apt-get build-dep -a $arch: wrong tradeoff for the default?
Date: Sat, 28 Jan 2012 14:14:54 -0800
[Message part 1 (text/plain, inline)]
tags 646288 patch
thanks

Hi there,

Attached is an updated version of the patch including fixes for the
integration tests, as requested by David.

Based on feedback from Linaro devs working on auto-cross-building support,
I'm planning on pushing this patch to Ubuntu precise.  Please let me know if
you see any problems with this patch.

Thanks,
-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org
[apt-646288.patch (text/x-diff, attachment)]
[signature.asc (application/pgp-signature, inline)]

Added tag(s) patch. Request was from Steve Langasek <vorlon@debian.org> to control@bugs.debian.org. (Sat, 28 Jan 2012 22:18:05 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, APT Development Team <deity@lists.debian.org>:
Bug#646288; Package apt. (Mon, 27 Feb 2012 23:12:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Alban Browaeys <prahal@yahoo.com>:
Extra info received and forwarded to list. Copy sent to APT Development Team <deity@lists.debian.org>. (Mon, 27 Feb 2012 23:12:06 GMT) Full text and rfc822 format available.

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

From: Alban Browaeys <prahal@yahoo.com>
To: Debian Bug Tracking System <646288@bugs.debian.org>
Subject: Re: apt-get build-dep -a $arch: wrong tradeoff for the default?
Date: Tue, 28 Feb 2012 00:09:19 +0100
[Message part 1 (text/plain, inline)]
Package: apt
Version: 0.8.16~exp13
Followup-For: Bug #646288

I had one issue with the previous patch with debhelper:all . Empty
InstVerIter and CandidateVersionIter. I fixed it by not applying the 
FindPkg(hostArch) for :All packages (ie this call replace the Pkg
iterator with a non existant arch versoin of the package).

Attached is the fix above the patch
http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=30;filename=apt-646288.patch;att=1;bug=646288
.

Best regards,
Alban


-- Package-specific info:

-- (no /etc/apt/preferences present) --


-- /etc/apt/sources.list --


# deb cdrom:[Debian GNU/Linux testing _Squeeze_ - Official Snapshot amd64 NETINST Binary-1 20100322-03:31]/ squeeze main 

# deb cdrom:[Debian GNU/Linux testing _Squeeze_ - Official Snapshot amd64 NETINST Binary-1 20100322-03:31]/ squeeze main 

deb http://ftp.uk.debian.org/debian/ experimental main non-free contrib 
deb-src http://ftp.uk.debian.org/debian/ experimental main non-free contrib 

deb http://ftp.fr.debian.org/debian/ unstable main non-free contrib 
deb-src http://ftp.fr.debian.org/debian/ unstable main non-free contrib 

deb http://ftp.fr.debian.org/debian/ wheezy main 
deb-src http://ftp.fr.debian.org/debian/ wheezy main 

deb http://security.debian.org/ wheezy/updates main 
deb-src http://security.debian.org/ wheezy/updates main 
# deb http://archive.canonical.com/ubuntu/ hardy partner 




-- System Information:
Debian Release: wheezy/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 3.3.0-rc1test0-00391-g9454d2f (SMP w/2 CPU cores)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages apt depends on:
ii  debian-archive-keyring  2011.10.23
ii  gnupg                   1.4.11-3
ii  libc6                   2.13-27
ii  libgcc1                 1:4.6.2-16
ii  libstdc++6              4.6.2-16
ii  zlib1g                  1:1.2.6.dfsg-2

apt recommends no packages.

Versions of packages apt suggests:
ii  apt-doc     <none>
ii  aptitude    0.6.5-1
ii  bzip2       1.0.6-1
ii  dpkg-dev    1.16.2~wipmultiarch
ii  lzma        9.22-2
ii  python-apt  0.8.4~exp1
ii  synaptic    0.75.5~exp6

-- no debconf information
[apt-get_fix2.diff (text/x-diff, attachment)]

Reply sent to Michael Vogt <mvo@debian.org>:
You have taken responsibility. (Tue, 06 Mar 2012 17:36:20 GMT) Full text and rfc822 format available.

Notification sent to Steve Langasek <vorlon@debian.org>:
Bug acknowledged by developer. (Tue, 06 Mar 2012 17:36:20 GMT) Full text and rfc822 format available.

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

From: Michael Vogt <mvo@debian.org>
To: 646288-close@bugs.debian.org
Subject: Bug#646288: fixed in apt 0.8.16~exp13
Date: Tue, 06 Mar 2012 17:32:36 +0000
Source: apt
Source-Version: 0.8.16~exp13

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

apt-doc_0.8.16~exp13_all.deb
  to main/a/apt/apt-doc_0.8.16~exp13_all.deb
apt-transport-https_0.8.16~exp13_amd64.deb
  to main/a/apt/apt-transport-https_0.8.16~exp13_amd64.deb
apt-utils_0.8.16~exp13_amd64.deb
  to main/a/apt/apt-utils_0.8.16~exp13_amd64.deb
apt_0.8.16~exp13.dsc
  to main/a/apt/apt_0.8.16~exp13.dsc
apt_0.8.16~exp13.tar.gz
  to main/a/apt/apt_0.8.16~exp13.tar.gz
apt_0.8.16~exp13_amd64.deb
  to main/a/apt/apt_0.8.16~exp13_amd64.deb
libapt-inst1.4_0.8.16~exp13_amd64.deb
  to main/a/apt/libapt-inst1.4_0.8.16~exp13_amd64.deb
libapt-pkg-dev_0.8.16~exp13_amd64.deb
  to main/a/apt/libapt-pkg-dev_0.8.16~exp13_amd64.deb
libapt-pkg-doc_0.8.16~exp13_all.deb
  to main/a/apt/libapt-pkg-doc_0.8.16~exp13_all.deb
libapt-pkg4.12_0.8.16~exp13_amd64.deb
  to main/a/apt/libapt-pkg4.12_0.8.16~exp13_amd64.deb



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 646288@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Michael Vogt <mvo@debian.org> (supplier of updated apt 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@debian.org)


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

Format: 1.8
Date: Tue, 06 Mar 2012 18:12:57 +0100
Source: apt
Binary: apt libapt-pkg4.12 libapt-inst1.4 apt-doc libapt-pkg-dev libapt-pkg-doc apt-utils apt-transport-https
Architecture: source all amd64
Version: 0.8.16~exp13
Distribution: experimental
Urgency: low
Maintainer: APT Development Team <deity@lists.debian.org>
Changed-By: Michael Vogt <mvo@debian.org>
Description: 
 apt        - commandline package manager
 apt-doc    - documentation for APT
 apt-transport-https - https download transport for APT
 apt-utils  - package managment related utility programs
 libapt-inst1.4 - deb package format runtime library
 libapt-pkg-dev - development files for APT's libapt-pkg and libapt-inst
 libapt-pkg-doc - documentation for APT development
 libapt-pkg4.12 - package managment runtime library
Closes: 619646 646288 649314 650513 657560 657695 657732 657902 658096 658346 662762
Changes: 
 apt (0.8.16~exp13) experimental; urgency=low
 .
   [ David Kalnischkies ]
   * apt-pkg/acquire-item.cc:
     - remove 'old' InRelease file if we can't get a new one before
       proceeding with Release.gpg to avoid the false impression of a still
       trusted repository by a (still present) old InRelease file.
       Thanks to Simon Ruderich for reporting this issue! (CVE-2012-0214)
     - add Debug::pkgAcqArchive::NoQueue to disable package downloading
   * apt-pkg/deb/dpkgpm.cc:
     - chroot if needed before dpkg --assert-multi-arch
     - ensure that dpkg binary doesn't have the chroot-directory prefixed
     - call dpkg --assert-multi-arch with execvp instead of execv
     - save the universe by not printing messages about apport if a package
       with this name is not installed (Closes: #619646)
     - handle a SIGINT in all modes as a break after the currently running
       dpkg transaction instead of ignoring it completely
   * apt-pkg/depcache.cc:
     - if a M-A:same package is marked for reinstall, mark all it's installed
       silbings for reinstallation as well (LP: #859188)
   * apt-pkg/contrib/configuration.cc:
     - do not stop parent transversal in FindDir if the value is empty
   * methods/http{s,}.cc:
     - if a file without an extension is requested send an 'Accept: text/*'
       header to avoid that the server chooses unsupported compressed files
       in a content-negotation attempt (Closes: #657560)
     - remove the arbitrary MAXLEN limit for response lines (Closes: #658346)
   * apt-pkg/aptconfiguration.cc:
     - chroot if needed before calling dpkg --print-foreign-architectures
     - ensure that architectures are not added multiple times
   * cmdline/apt-mark.cc:
     - detect if dpkg has multiarch support before calling --set-selections
     - correctly ignore already (un)hold packages
   * apt-pkg/cachefile.cc:
     - clean up lost atomic cachefiles with 'clean' (Closes: #650513)
   * apt-pkg/indexrecords.cc:
     - do not create empty Entries as a sideeffect of Lookup()
   * apt-pkg/acquire-item.cc:
     - drop support for i18n/Index file (introduced in 0.8.11) and use
       the Release file instead to get the Translations (Closes: #649314)
     - use pdiff for Translation-* files if available (Closes: #657902)
   * ftparchive/writer.cc:
     - add 'Translation-*' to the default patterns
   * cmdline/apt-get.cc:
     - if a package can't be removed as it is not installed, suggest to
       the user an (installed) multiarch silbing with 'Did you mean?'
     - improve 'error' message for packages which are only referenced
       e.g. in a Depends line and are now requested for removal
   * cmdline/apt-cache.cc:
     - correct --pre-depends option by using dash consistently (LP: #940837)
   * apt-pkg/packagemanager.cc:
     - do not try to a void a breaks if the broken package pre-depends
       on the breaker, but let dpkg auto-deconfigure it
   * apt-pkg/contrib/fileutl.cc:
     - do not warn about the ignoring of directories (Closes: #662762)
 .
   [ Steve Langasek ]
   * cmdline/apt-get.cc:
     - for cross-build-dependencies M-A: none should be DEB_HOST_ARCH,
       not DEB_BUILD_ARCH (Closes: #646288)
 .
   [ Colin Watson ]
   * apt-pkg/algorithms.cc:
     - don't break out of the main-resolver loop for Breaks to deal with all
       of them in a single iteration (Closes: #657695, LP: #922485)
     - use a signed int instead of short for score calculation as upgrades
       become so big now that it can overflow (Closes: #657732, LP: #917173)
   * Fix IndexCopy::CopyPackages and TranslationsCopy::CopyTranslations to
     handle compressed files again (LP: #924182, closes: #658096)
 .
   [ Michael Vogt ]
   * apt-pkg/deb/dpkgpm.cc:
     - fix crash when a package is in removed but residual config state
       (LP: #923807)
   * apt-pkg/contrib/fileutl.h:
     - fix compat with FileFd::OpenDescriptor() in ReadOnlyGzip mode
   * apt-pkg/packagemanager.cc:
     - fix bug in predepends handling - ensure that packages that needs
       unpackaging are unpacked before they are configured (LP: #927993)
 .
   [ Julian Andres Klode ]
   * apt-pkg/deb/deblistparser.cc:
     - Set the Essential flag on APT instead of only Important
   * apt-pkg/packagemanager.cc:
     - Do not use immediate configuration for packages with the Important flag
   * Treat the Important flag like the Essential flag with those differences:
     - No Immediate configuration (see above)
     - Not automatically installed during dist-upgrade
     - No higher score for installation ordering
Checksums-Sha1: 
 32ba0d502d1e73af5918b5b7dd06a6a62cb73a0a 1690 apt_0.8.16~exp13.dsc
 7601a34f5ca64bf7ff45b6daf8266f2c473dd06b 3402230 apt_0.8.16~exp13.tar.gz
 3b4edc5ff5e77ebf0b124c3055489db8bdca72e5 251982 apt-doc_0.8.16~exp13_all.deb
 70f37715459d2834474358745080d36e51d0bd46 829466 libapt-pkg-doc_0.8.16~exp13_all.deb
 e5799a01fa7c917f3376f25868883f2c6342d50a 1015192 libapt-pkg4.12_0.8.16~exp13_amd64.deb
 bdb04d9f4c7679a7f40b8e615f92e939ed6a7421 186948 libapt-inst1.4_0.8.16~exp13_amd64.deb
 623fd35eb83dba3fffc0b5263aad211c0a5024e4 1164922 apt_0.8.16~exp13_amd64.deb
 4572ec2c4eeaf146dad9ef40b4d0c0794bfedc68 175832 libapt-pkg-dev_0.8.16~exp13_amd64.deb
 dbedaabb89b071234c9891df79a5f4d7f3a1f269 272420 apt-utils_0.8.16~exp13_amd64.deb
 f4b6b505783c4cfdcb5cbda6a590b3d95345f20c 98362 apt-transport-https_0.8.16~exp13_amd64.deb
Checksums-Sha256: 
 752fe0120e4b5be7d8bb065fa903c082ddc09330894d404d3b385097631939f1 1690 apt_0.8.16~exp13.dsc
 5cde730a24638ccbcfac5089644db56388d3650f7c61bf768555fa3db308ce59 3402230 apt_0.8.16~exp13.tar.gz
 adeacff9bbd89cfee1c1faf4a966c36ea006a4c554980b1e1b90cc3e8018bff5 251982 apt-doc_0.8.16~exp13_all.deb
 7a6e1410de78715e82d57a7deb8a86ef80610cad0ded4979d768ca54a52021e1 829466 libapt-pkg-doc_0.8.16~exp13_all.deb
 013d26a664eea5e3624415f0664c38ca955f0cbbc106776d5e3215dd5769c07e 1015192 libapt-pkg4.12_0.8.16~exp13_amd64.deb
 9e8d23220bb22eef341619c2fbfc0c8ccc508eaded82fea9bcc38798f5171bd8 186948 libapt-inst1.4_0.8.16~exp13_amd64.deb
 928bd77863b9edd67f83a5300d0fbf81bba2cf84743a7716d9c0676267730927 1164922 apt_0.8.16~exp13_amd64.deb
 30dad707728310b160f4a31d9ce7219ec3c48e23d5bd389ccc30a7861cee79b7 175832 libapt-pkg-dev_0.8.16~exp13_amd64.deb
 0f14b7537e66d43a7e4dd5fdf41eaf52bebec12a975a9fa53a075603bcfe76c1 272420 apt-utils_0.8.16~exp13_amd64.deb
 690ea82b8a05baed990abe72b14e5781cc1a6ff2da7678d4c0c258b13e5656a2 98362 apt-transport-https_0.8.16~exp13_amd64.deb
Files: 
 36fec50713ebb62b5f8d0457e433029d 1690 admin important apt_0.8.16~exp13.dsc
 64d460c47b1b58e42e1f70be86ddb250 3402230 admin important apt_0.8.16~exp13.tar.gz
 2efa431d666c7e7cf5d66b8ef4d337b4 251982 doc optional apt-doc_0.8.16~exp13_all.deb
 2769797e1e9c27ae54a6784d8e20761b 829466 doc optional libapt-pkg-doc_0.8.16~exp13_all.deb
 4964a90d91f9bdbacf7a77de1d85ebf1 1015192 admin important libapt-pkg4.12_0.8.16~exp13_amd64.deb
 6d0f84a70da94ece33a6529dc005626a 186948 admin important libapt-inst1.4_0.8.16~exp13_amd64.deb
 5062a82fde1e0bd3a0875051f01022e1 1164922 admin important apt_0.8.16~exp13_amd64.deb
 cd77bd303d6f44d8097b318910096d3f 175832 libdevel optional libapt-pkg-dev_0.8.16~exp13_amd64.deb
 e499a62db417c3251e93401bcd24ff5b 272420 admin important apt-utils_0.8.16~exp13_amd64.deb
 9eebcaa60ccb01dd3828e278f4e632d8 98362 admin optional apt-transport-https_0.8.16~exp13_amd64.deb

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

iEYEARECAAYFAk9WRsgACgkQliSD4VZixzR7hgCfXYmM1w1sxB463L18bu/M9L9t
StsAni0R4HU3lhuIozpuwZiVkxm0MSJh
=6Tva
-----END PGP SIGNATURE-----





Bug archived. Request was from Debbugs Internal Request <owner@bugs.debian.org> to internal_control@bugs.debian.org. (Wed, 04 Apr 2012 07:40:09 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: Sun Apr 20 21:36:53 2014; Machine Name: buxtehude.debian.org

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