Re: Bug#671302: Circular Build Dependencies (was Bug#671302: libav: circular dependency between libav and opencv)
On Sat, May 5, 2012 at 5:48 AM, Simon McVittie <smcv@debian.org> wrote:
> On 04/05/12 21:45, Andres Mejia wrote:
>> On May 4, 2012 4:43 PM, "Fabian Greffrath" <fabian@greffrath.com
>> <mailto:fabian@greffrath.com>> wrote:
>>>
>>> > libav -> x264 -> libav
>>>
>>> AFAICT the x264 frontend uses libav whereas libav uses the libx264 shared
>>> library. So theortically (!) this issue could be solved by two separate
>>> source packages for the x264 frontend and the library.
>
> This would also be pretty straightforward via the DebianBootstrap
> proposal from the wiki: the stage-1 build of x264 would only compile the
> library, and omit the front-end.
>
> I believe the current state-of-the-art for bootstrapping new
> architectures, or getting a particularly "slow" architecture caught up,
> is essentially to do the equivalent of that proposal, but by hand
> (dpkg-buildpackage -d, and maybe temporary source changes that are never
> uploaded).
>
> dbus and dbus-glib also have cyclic build-dependencies: you can break
> the cycle by ignoring the dbus-glib dependency (which means most of the
> dbus regression tests aren't compiled), then building dbus-glib, then
> rebuilding dbus against it. In the absence of a finalized version of the
> bootstrap proposal, this is documented in comments in debian/control.
>
>> This doesn't resolve the issue with opencv though.
>
> What's the cycle here? Can it also be broken by temporarily taking out
> similar optional functionality - tests or front-ends or something?
It was libav -> opencv -> libav. It can be broken by temporarily
taking out opencv support.
> S
>
>
> --
> To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
> Archive: [🔎] 4FA4F75F.6060205@debian.org">http://lists.debian.org/[🔎] 4FA4F75F.6060205@debian.org
>
I suppose the proposal offers a good solution to break these circular
build dependencies. I imagine the buildd network can treat these
staged build depends as regular build depends (i.e. have states like
"Stage N BD-Uninstallable"). It can iterate through the stages
starting from the final stage until the first stage, checking which
stage it can build. Then from there, it can iterate back up the
stages, building each stage until it builds the final stage packages.
So something like this.
STAGE_BUILDS
stage = n
for i from n to 1
stage = i
if build depends for stage i satisfiable then
break
for i from stage to n
build stage i
--
~ Andres
Reply to: