[buildd-tools-devel] Bug#559655: Bug#559655: sbuild: dealing with experimental is (less of?) a PITA

Cyril Brulebois kibi at debian.org
Fri Mar 19 03:12:16 UTC 2010


Hi Roger.

Roger Leigh <rleigh at codelibre.net> (13/12/2009):
> There are IIRC some extra patches needed to make sbuild work nicely
> when building experimental packages.  I did at one point merge some
> changes needed for experimental autobuilding, but I think there may
> be some outstanding patches which are missing.

I think so. I didn't notice anything related which would differ
between “my” experimental kfreebsd-* buildds (using packages built
from the buildd branch AFAICT), and my (sid-using) local sbuild setup.

> I'll CC HE, who is probably the best person to ask about experimental
> autobuilding AFAIK!

Marc? :)

> I am not aware of any specific setup HOWTO or other documentation
> about configuring a Debian system to build from experiemental.  I
> would be happy to add support for that to sbuild if I could, plus
> add automatic setup of any specific chroot configuration such as APT
> pinning etc.  I just don't have the specific knowledge to do this
> I'm afraid, but I'm always happy to accept patches or suggestions
> from those that do!

In the meanwhile, people could be pointed to the following option,
which AFAICT isn't listed in the manpage yet:
| --build-dep-resolver=aptitude

Context: I've been trying to rebuild some packages providing udebs
against versions of cairo/pango/gtk sitting in experimental (details
in [1]).

 1. http://lists.debian.org/debian-boot/2010/03/msg00313.html

My findings so far, when using this option, and no pinning at all:

 * If one B-D on libfoo-dev (>= foover), with foover only available in
experimental, that works fine; both libfoo-dev and libfoo are pulled
from experimental. Unfortunately, if libfoo pulls libbar (= barver),
with barver in experimental, and one only B-D on libbar (>=
previousbarver) with previousbarver in unstable, one ends up trying to
install libbar-dev from unstable (because it's sufficient for the
Build-Depends), and libbar from experimental (because it was computed
as needed to satisfy some dependencies).

 * This results in broken packages. It can be worked around, though,
by using an extra option: --add-depends='libbar (>= barver)', with
several packages if needed.


I agree this is suboptimal, but still far better than trying to
manually install packages from experimental by logging into the chroot
as described in my initial bugreport, and having to clean the mess up
afterward.

Depending on Marc's reply, you might want to document those options as
a possible way to deal with experimental, until proper support is
added and/or documented.

Mraw,
KiBi.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/buildd-tools-devel/attachments/20100319/05db84d2/attachment.pgp>


More information about the Buildd-tools-devel mailing list