Bug#812173: apt fails to distinguish between different Provides of different package versions
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 to: