Bug#178121: apt build-dep does not parse versions of packages correctly
Package: apt
Version: 0.5.4
Severity: normal
Dear People,
I just went through the apt bugs (there are a lot of them) but didn't see
this one. Maybe it is there but I missed it; I searched for "build" in the
headers.
Anyway, I would rate the importance of this bug above normal, but it would
probably get downgraded if I set it to important. Anyway...
The following report was sent by me as a followup to #171542, but that might
be a different issue. The problem with what follows seems quite clear. Apt
does not seem to check correctly, or possibly does not check at all (I am
not sure which) for the correct versions of packages in build-depends of
binaries. It appears to ignore syntax like >= etc. Possibly it will install
any version available and ignore versioning, I don't know.
Here is a simple current example.
Try getting the build-dependencies for subversion (currently only in
unstable) on a testing system. It will happily get the version 1.3.14-1 of
swig1.3, but in fact the version required is swig1.3 (>=1.3.16).
Here are the build dependencies for subversion
Source: subversion
Version: 0.16.0-1
Build-Depends: debhelper, libneon23-dev, apache2-dev (>=2.0.42),
libapr0-dev (>=2.0.42), libdb4.0-dev, libtool (>=1.4), libexpat1-dev,
zlib1g-dev, bison, patch, python, time, python2.2-dev, texinfo,
autotools-dev, autoconf (>=2.53), swig1.3 (>=1.3.16)
Now I run
Chrestomanci:/etc/apt# apt-get build-dep subversion
Reading Package Lists... Done
Building Dependency Tree... Done
The following packages will be REMOVED:
libdb2-dev
The following NEW packages will be installed:
apache2-common apache2-dev libapr0 libapr0-dev libdb4.0 libdb4.0-dev
libgdbmg1-dev libneon23 libneon23-dev libpcre3-dev
libswig1.3 libxml2-dev libxmltok1 libxmltok1-dev python2.2-dev swig1.3
0 packages upgraded, 16 newly installed, 1 to remove and 0 not
upgraded.
Need to get 5538kB of archives. After unpacking 23.5MB will be used.
Do you want to continue? [Y/n]
The version of swig1.3 installed is then
ii swig1.3 1.3.14-1 Generate scripting
interfaces to C/C++ code.
faheem /usr/local/src/subversion/subversion-0.16.0>debuild binary
dpkg-checkbuilddeps: Unmet build dependencies: swig1.3 (>=1.3.16)
You do not appear to have all build dependencies properly met.
So it installed 1.3.14-1 though actually 1.2.16 was needed.
Some additional comments:
1) The original build-dep gave no indication of problems, and so I went
ahead with the downloading of these packages, which in the end turned out
not to be very useful.
2) If I run apt-get build-dep subversion again it does say
Chrestomanci:/etc/apt# apt-get build-dep subversion
Reading Package Lists... Done
Building Dependency Tree... Done
Sorry, swig1.3 is already the newest version.
so it sort of notices that something is wrong, but really it should return
some kind of clear indication that the build-dependencies were not
properly met.
3) Note that since subversion is only in unstable, it cannot be a case of apt
trying to use the build-dependencies for another version of the subversion
source. I'm not completely sure what the rule for this is, in any case.
4) I remember encountering this problem in 2001 when I had potato installed
with apt 0.5.4 and was compiling packages from source code in unstable, but
at the time I was too lazy to follow it up. So the problem is not confined
to this package. Is this a known problem or not? I have never come across
this problem clearly described in the apt bug database.
Can someone point me to where the build-dep method code is located? I'll
take a look at it.
Incidentally, is there anything I can do to get the 0.5.5 release out of the
door? I heard there were some problems, but don't know the current status.
Faheem.
-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux Chrestomanci 2.4.17 #1 Mon Jun 24 18:03:29 EDT 2002 i686
Locale: LANG=C, LC_CTYPE=C
Versions of packages apt depends on:
ii libc6 2.2.5-14.3 GNU C Library: Shared libraries an
ii libstdc++2.10-glibc2.2 1:2.95.4-11woody1 The GNU stdc++ library
-- no debconf information
Reply to: