Package: apt
Version: 1.2
Severity: serious
Justification: Policy 7.5
Control: affects -1 + src:libjpeg9

Hi,

steps to reproduce for apt-get build-dep:

    $ sudo debootstrap --include=equivs sid debian-apt-bug  
http://snapshot.debian.org/archive/debian/20160119T151500Z
    $ echo deb-src http://snapshot.debian.org/archive/debian/20160119T151500Z 
sid main | sudo tee -a debian-apt-bug/etc/apt/sources.list
    $ sudo chroot debian-apt-bug apt-get update
    $ sudo chroot debian-apt-bug apt-get build-dep libjpeg9
    Reading package lists... Done
    Building dependency tree... Done
    The following NEW packages will be installed:
      autoconf automake autopoint build-essential cpp cpp-5 dh-autoreconf g++ 
g++-5 gcc gcc-5 libasan2 libatomic1
      libc-dev-bin libc6-dev libcc1-0 libcilkrts5 libgcc-5-dev libisl15 libitm1 
liblsan0 libmpc3 libmpfr4 libmpx0
      libquadmath0 libsigsegv2 libstdc++-5-dev libtool libtsan0 libubsan0 
linux-libc-dev m4
    0 upgraded, 32 newly installed, 0 to remove and 0 not upgraded.
    Need to get 102 MB of archives.
    [...]
    Get:7 http://snapshot.debian.org/archive/debian/20160119T151500Z sid/main 
amd64 automake all 1:1.15-3 [735 kB]
    [...]
    Selecting previously unselected package automake.
    Preparing to unpack .../automake_1%3a1.15-3_all.deb ...
    Unpacking automake (1:1.15-3) ...
    [...]
    $ sudo chroot debian-apt-bug apt-get source --build libjpeg9
    dpkg-checkbuilddeps: error: Unmet build dependencies: automake-1.14
    dpkg-buildpackage: warning: build dependencies/conflicts unsatisfied; 
aborting
    dpkg-buildpackage: warning: (Use -d flag to override.)
    Build command 'cd libjpeg9-9a && dpkg-buildpackage -b -uc' failed.

As you can see from above, dpkg-checkbuilddeps and apt-get build-dep
disagree. This might be because unstable currently carries two automake
packages in different versions:

    Package: automake
    Source: automake-1.14
    Version: 1:1.14.1-4
    Architecture: all
    Provides: automake-1.14, automaken
    Depends: autoconf (>= 2.65), autotools-dev (>= 20020320.1)
    Conflicts: automake (<< 1:1.4-p5-1), automake1.10-doc, automake1.5 (<< 
1.5-2), automake1.6 (<< 1.6.1-4)
    Multi-Arch: foreign
    
    Package: automake
    Source: automake-1.15
    Version: 1:1.15-3
    Architecture: all
    Provides: automake-1.15, automaken
    Depends: autoconf (>= 2.65), autotools-dev (>= 20020320.1)
    Suggests: autoconf-doc, gnu-standards
    Conflicts: automake (<< 1:1.4-p5-1), automake1.10-doc, automake1.5 (<< 
1.5-2), automake1.6 (<< 1.6.1-4)
    Multi-Arch: foreign

Steps to reproduce for apt-get install:

    $ cat > control << END
    > Package: dummy
    > Depends: automake-1.14
    > END
    $ equivs-build control
    $ apt-get install ./dummy_1.0_all.deb
    The following packages have unmet dependencies:
     dummy : Depends: automake-1.14
    E: Unable to correct problems, you have held broken packages.

It seems automake (= 1:1.14.1-4) provides automake-1.14 while automake
(= 1:1.15-3) provides automake-1.15. It might be that somehow apt sees
that "automake" provides automake-1.14 but does not store which version
of "automake" provides it and just either installs the newest one in the
"apt-get build-dep" case or only picks the newest one as a candidate and
then fails to satisfy the dependency because that version doesn't
provide automake-1.14.

Ideally, apt should see that there are different versions of the same
package with the same pin value but different provides and pick the one
that satisfies the dependency even if it's of a lower version. After
all, both packages are part of the same suite. Though with apt's
behaviour of selecting only the highest version as the candidate I can
see why this will not be happening and maybe instead automake should
change how they do their virtual packages. But then again, on what
grounds should automake change their provides? Only because of an apt
limitation? As far as I can see they are policy compliant and other
resolvers like dose3 or aspcud will happily find a solution.

The clear policy violation here is the "apt-get build-dep" problem
because apt installs a package that is not satisfying the build
dependency at hand. This has to be fixed. At least just fail in the same
way as during binary package installation.

What do you think?

cheers, josch

Reply via email to