[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: haskell-uulib build failure


Am Donnerstag, den 09.07.2009, 08:41 -0300 schrieb Marco Túlio Gontijo e
> Em Wed, 08 Jul 2009 21:47:48 +0200
> Joachim Breitner <nomeata@debian.org> escreveu:
> (...)
> > haskell-uulib_0.9.10-0.1 (nmu by Marco) fails due to:
> > 
> > > Configuring uulib-0.9.10...
> > > hlibrary.setup: ffihugs is required but it could not be found.
> > 
> > Marco, did you see that?
> No, sorry.  But it seems to be caused by:
> Build-Depends-Indep: haddock, hugs, ghc6-doc, hscolour (>= 1.8)
> Doesn't buildd installs Build-Depends-Indep before building the packages?
> $ dpkg -L hugs | grep /usr/bin/ffihugs
> /usr/bin/ffihugs

Isn’t that the point of Build-Depends-Indep: To avoid having the buildds
install stuff that’s not needed to build only the arch-dependent

Let’s see what the policy says at

The dependencies and conflicts they define must be satisfied (as defined
earlier for binary packages) in order to invoke the targets in
debian/rules, as follows:[45]

Build-Depends, Build-Conflicts
        The Build-Depends and Build-Conflicts fields must be satisfied
        when any of the following targets is invoked: build, clean,
        binary, binary-arch, build-arch, build-indep and binary-indep.
Build-Depends-Indep, Build-Conflicts-Indep
        The Build-Depends-Indep and Build-Conflicts-Indep fields must be
        satisfied when any of the following targets is invoked: build,
        build-indep, binary and binary-indep.
If you make "build-arch" or "binary-arch", you need Build-Depends. If
you make "build-indep" or "binary-indep", you need Build-Depends and
Build-Depends-Indep. If you make "build" or "binary", you need both.

There is no Build-Depends-Arch; this role is essentially met with
Build-Depends. Anyone building the build-indep and binary-indep targets
is basically assumed to be building the whole package anyway and so
installs all build dependencies. The autobuilders use dpkg-buildpackage
-B, which calls build (not build-arch, since it does not yet know how to
check for its existence) and binary-arch.

The purpose of the original split, I recall, was so that the
autobuilders wouldn't need to install extra packages needed only for the
binary-indep targets. But without a build-arch/build-indep split, this
didn't work, since most of the work is done in the build target, not in
the binary target.


Now what happens at

We see that it parsed the field:

> ** Using build dependencies supplied by package:
> Build-Depends: debhelper (>= 5), cdbs, ghc6 (>= 6.8.2), ghc6-prof (>= 6.4.2), haskell-devscripts (>= 0.6.15+nmu1), cpphs
> Build-Depends-Indep: haddock, hugs, ghc6-doc, hscolour (>= 1.8)

but did not actually install haddock or any of the others.

It then calls
$ /usr/bin/fakeroot debian/rules clean
$ debian/rules build
which eventually tries to build the hugs package and fails.

So something is wrong, but I don’t know what :-). I haven’t used
Build-Depends-Indep myself until I copied debian/control from you...

It might be that cdbs is the problem:

> I'd like to easily be able to tell from debian/rules whether this is 
> going to be an arch or an arch + indep build in general; this is not 
> trivial with a common build rule for both cases as in CDBS at the 
> moment.   :-/

dpkg-buildpackage should support it since 1.10.11:
> * Patch dpkg-buildpackage to call debian/rules -qn build-arch, and if
>      it's available, modify -B handling appropriately.  If build-arch is not
>      available, then when -B was called, do *not* pass -B on to
>      dpkg-checkbuilddeps.  Closes: #203097
But maybe "make -qn" does not work nicely with cdbs.

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=197100 is also enlighting.

Maybe we should just put all in Build-Depends, forget about
Build-Depends-Indep, until this is solved properly in cdbs, dpkg-dev,
buildds and elsewhere :-)



Joachim "nomeata" Breitner
Debian Developer
  nomeata@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: nomeata@joachim-breitner.de | http://people.debian.org/~nomeata

Attachment: signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

Reply to: