Re: ocaml 3.10.2 transition scheduled for next week
On Wed, May 14, 2008 at 04:28:07PM +0200, Romain Beauxis wrote:
> Le Wednesday 14 May 2008 16:20:22 Sven Luther, vous avez écrit :
> > > Hence, ocaml-compiler-libs is pulled from etch, which itself pulls ocaml
> > > 3.09.2-9 which turns out to be incompatible with the ocaml-nox from
> > > backports.org, installed as a forced versioned dependency.
> >
> > Romain, why is ocaml-ompiler-libs pulled from etch, and not from
> > backport.org ? This seem to be the fundamental problem you are
> > experiencing, and the fact that this breaks, is probably a feature and
> > not a bug.
>
> Yea :)
> As I said, backports.org and experimental buildds try to pull the less
> possible packages from backports.org/experimental.
>
> The real bug for me is the impossibility to reproduce it beforehand. Hence,
> it's defined as it's implemented...
>
> > > The same issue happen for experimental.
> > >
> > > My opinion on this is that build dependencies for packages using both
> > > ocaml-nox and other incompatible packages should be versioned for all of
> > > them, but perhaps it is also possible to add lines in the form of:
> > > Conflicts: xxx (>>${binary:Version}), xxx (<<${binary:Version})
> > > in the control file from ocaml source package, where necessary..
> >
> > Did we not use the ocaml-<version> and co virtual packages for this ?
>
> Yes, so ocaml-ompiler-libs pulled from etch requires ocaml-nox-OLD_API, which
> later conflicts and then break the whole resolution process.
>
> Of course, a more correct resolution would recover from the failure and try
> another ocaml-ompiler-libs, like from backports.org
>
> This could be a bug at buildd's side don't you think ?
just depend on ocaml-compiler-libs-<API> and be done with it ?
I seriously think the issue is the same one we used to have 2-3 years
ago about backports, maybe you should look at the old archive of the
mailign list about it.
As i remember the thing, packages should be able to build with any
ocaml-API, but you needed to generate the control from a control.in,
which looked at the ocamlc being used and grabbed the API from that or
something, i think ocaml-nox installed the API in some file which was
read. This API number can then be used to place in control all the APIed
version of the dependencies, and the buildd have then no problem in
grabbing those.
I think that there was a bug in 2001/2002 in the buildd about virtual
packages, of which James Troup told me : it is not supported by buildds,
so don't do it, but i spoke with James and Anthony at debconf oslo about
it, and i think it has been solved since then, my memory may be sketchy
though.
That said, when we did the above, CDBS using packages had some built
debian/control.in calls which kind of break this, not sure what happened
since them, i myself think SDBS is an abomination, but then to everyone
his own :)
Friendly,
Sven Luther
>
>
>
> Romain
> --
> son, daddy left you were from you were four
> I've got to struggle 'cos I am poor
> she said, food is a very hard thing to find
> sometime I feel like I'm going out of my mind
>
>
> --
> To UNSUBSCRIBE, email to debian-ocaml-maint-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
>
Reply to: