<p>On May 3, 2012 9:30 AM, "Pino Toscano" <<a href="mailto:pino@debian.org">pino@debian.org</a>> wrote:<br>
><br>
> Alle giovedì 3 maggio 2012, Andres Mejia ha scritto:<br>
> > On Thu, May 3, 2012 at 3:44 AM, Pino Toscano <<a href="mailto:pino@debian.org">pino@debian.org</a>> wrote:<br>
> > > Package: libav<br>
> > > Version: 6:0.8.1-7<br>
> > > Severity: important<br>
> > ><br>
> > > Hi,<br>
> > ><br>
> > > libav 6:0.8.1-7 reenables the use of opencv... which itself uses<br>
> > > libav libraries. This currently makes libav unbuildable on mipsel<br>
> > > and hurd-i386, and generically makes libav no more bootstrap'able<br>
> > > without having itself compiled already.<br>
> > > Could you please drop the opencv usage again, please?<br>
> > ><br>
> > What could be done instead is a binary only upload with opencv<br>
> > support disabled (i.e. use dpkg-buildpackage -B). Doing it on our<br>
> > end will not require changing the version. Once this package is<br>
> > uploaded, the release team can then be asked to do a binNMU for<br>
> > these archs, which will bring back opencv support since the archive<br>
> > will contain the regular *.debian.tar.gz changes that included<br>
> > opencv.<br>
> ><br>
> > I believe this is better than doing a full build on all archs without<br>
> > opencv, then doing another build with opencv.<br>
><br>
> This mess (which is only a mess, not a clean solution) does not solve at<br>
> all the fact that you cannot do a clean build of libav without having<br>
> libav compiled already (for opencv).<br>
> I don't see this as a viable solution, especially if in the future the<br>
> epoch is raised bringing again conflicts between the old libav libraries<br>
> and the new one.<br>
><br>
> --<br>
> Pino Toscano</p>
<p>I'm not entirely certain how build circular dependency issues like this are resolved. Perhaps we should ask for help from the toolchain package maintainers or debian-devel.</p>
<p>~ Andres</p>