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

Re: Bootstrapping: list of 81 self-cycles in Debian Sid


Quoting The Wanderer (2013-03-05 15:35:37)
> You can build either one without a matching version of the other, but you
> won't get full functionality. In order to get the full functionality of both,
> from what I've been able to tell you need a minimum of three builds on every
> cross-matching-version update: x264 without libavformat support, then FFmpeg
> with x264 support, then x264 with libavformat support. (Or possibly the
> reverse, but x264 is faster to build than FFmpeg is.)

Assuming you build x264 without libavformat, the correct order is actually:

 1. src:x264 without libavformat-dev

 2. src:libav fully

 3. src:x264 fully

 4. src:libav fully again

We add the fourth step so that it is less likely that a libx264-dev with
limited functionality influences the binaries built by src:libav in some funny

Though in practice, src:x264 as well as src:libav are part of a big 900-1000
vertices big strongly connected component. So the actual build order is:

 1. build tons of source packages (all source packages in the strongly
    connected component, so about 380-400), some of them fully, some of them
    with reduced dependencies

 2. rebuild all source packages fully which were earlier built with reduced

 3. rebuild the rest of source packages fully

> At a glance, this looks to me like a variant of the self-cycle problem. Is it
> something which should/could be addressed as part of the same effort? Or is it
> already handled in Debian in a way I haven't noticed? Or "none of the above"?

Maybe I didnt understand you correctly but maybe it helps if I note that the
example you give is not a self-cycle but a cycle of length two (or four
depending on the type of dependency graph).

Go to this wiki page:


And search for this string:

	src:libav -> libx264-dev -> src:x264 -> libavformat-dev

This is the cycle that you took as an example earlier. So yes, we can also find
those cyclic dependencies but they are a different problem class because
instead of having just one way to break them, there are now two:

 1. either building src:libav without libx264-dev

 2. or building src:x264 without libavformat-dev

But those cycles are a bit less interesting because there are two possibilities
to break it. So a bootstrapper must go and decide which of the two to build
with reduced dependencies depending on which one is easier to modify, faster to
build or because the structure of the surrounding dependency graph indicates
that one build dependency has a much higher impact of the overall graph
structure than the other. Our tools help to make the latter decision easier.

I hope this helps a bit.

cheers, josch

Reply to: