[Buildd-tools-devel] Bug#395271: sbuild: doesn't handle dependancies resolution correctly for libmail-box-perl

[Lucas Nussbaum]

On 26/05/07 at 08:58 +0300, Guillem Jover wrote:
> reassign 395271 sbuild
> retitle 395271 sbuild: incorrectly handles versioned provides
> thanks
> 
> On Fri, 2006-10-27 at 23:15:29 +0100, Roger Leigh wrote:
> > Lucas Nussbaum <lucas at lucas-nussbaum.net> writes:
> > > While trying to build libmail-box-perl using sbuild, I ran into a
> > > problem: it seems that sbuild doesn't resolve the build-deps
> > > correctly when it involves dealing with Provides. Here is the log:
> > 
> > > libscalar-list-utils-perl: already installed (=*=PROVIDED=*= >= 1.13 is
> > > satisfied)
> > > dpkg-source: warning: could not verify signature on
> > > /tmp/build/libmail-box-perl_2.068-1.dsc since gpg isn't installed
> > > dpkg-source: extracting libmail-box-perl in libmail-box-perl-2.068
> > > dpkg-source: unpacking libmail-box-perl_2.068.orig.tar.gz
> > > dpkg-source: applying /tmp/build/libmail-box-perl_2.068-1.diff.gz
> > > dpkg-buildpackage: source package is libmail-box-perl
> > > dpkg-buildpackage: source version is 2.068-1
> > > dpkg-buildpackage: host architecture i386
> > > dpkg-buildpackage: source version without epoch 2.068-1
> > > dpkg-checkbuilddeps: Unmet build dependencies: libtest-harness-perl (>=
> > > 2.62)
> > > dpkg-buildpackage: Build dependencies/conflicts unsatisfied; aborting.
> > > dpkg-buildpackage: (Use -d flag to override.)
> > 
> > > It would be great if either:
> > > - sbuild could say which package provides a specific dependancy, to help
> > >   debugging this
> > > - this was handled correctly (but I'm not sure of what "correctly" means
> > >   here)
> > 
> > It's dpkg-checkbuilddeps (part of dpkg-dev) that's failing, rather
> > than sbuild.  I'm reassigning to dpkg-dev.
> 
> dpkg-checkbuilddeps supports Provides correctly, the problem here is
> that it does not support versioned Provides (as is the case for the
> whole package managment stack). So I suppose sbuild should fail
> sooner, and all those perl packages should be fixed to update their
> Build-Dependencies (given that perl-modules is Build-Essential, just
> removing the offending packages which are provided by it should be
> enough).

It's not that simple, actually. Let's consider svk 2.0.1-1:
** Using build dependencies supplied by package:
Build-Depends: debhelper (>= 4.0.2)
Build-Depends-Indep: perl (>= 5.8.0-7), gnupg, libalgorithm-annotate-perl, libalgorithm-diff-perl (>> 1.19.01), libapp-cli-perl, libclass-accessor-perl, libclass-autouse-perl (>> 1.15), libclass-data-inheritable-perl, libcompress-zlib-perl, libdata-hierarchy-perl (>> 0.30), libfile-spec-perl (>> 3.17), libfile-temp-perl (>> 0.17), libfreezethaw-perl, libio-digest-perl, liblist-moreutils-perl, liblocale-maketext-lexicon-perl (>> 0.62), liblocale-maketext-simple-perl (>> 0.16), libpath-class-perl (>> 0.16), libperlio-eol-perl (>> 0.13), libperlio-via-dynamic-perl (>> 0.11), libperlio-via-symlink-perl (>> 0.02), libpod-escapes-perl, libpod-simple-perl, libsvn-mirror-perl (>> 0.71), libsvn-simple-perl (>> 0.27), libterm-readkey-perl, libuniversal-require-perl, liburi-perl, libversion-perl, libyaml-syck-perl (>> 0.60)
[...]
libfile-temp-perl: already installed (=*=PROVIDED=*= >> 0.17 is satisfied)
[...]
dpkg-checkbuilddeps: Unmet build dependencies: libfile-temp-perl (>> 0.17)
dpkg-buildpackage: Build dependencies/conflicts unsatisfied; aborting.

It build-depends on perl, which itself depends on perl-modules, which
provides libfile-temp-perl. However, the version of File/Temp.pm in
perl-modules is 0.16. So the maintainers knows this one is not enough,
and explicitely requests >> 0.17.

I think that the correct way to handle that on sbuild side is to install
the specified package even if the package is provided by another
package, in the case it's a versioned depend. So that would give
something like:
libfile-temp-perl: provided by an installed package, but versioned dependancy => missing

I have the same problem with lots of packages that b-dep on
linux-kernel-headers (>> 2.5.999), since I switched to linux-libc-dev,
and linux-kernel-headers is provided by linux-libc-dev.
 
How hard would that be to implement something like that ?
-- 
| Lucas Nussbaum
| lucas at lucas-nussbaum.net   http://www.lucas-nussbaum.net/ |
| jabber: lucas at nussbaum.fr             GPG: 1024D/023B3F4F |