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

Re: Ocaml 3.08.0-2 ready to enter testing, hold back by 54+4 packages.



On Fri, Aug 06, 2004 at 08:55:34AM -0500, John Goerzen wrote:
> On Fri, Aug 06, 2004 at 03:39:53PM +0200, Sven Luther wrote:
> > On Fri, Aug 06, 2004 at 10:07:55AM +0200, Julien Cristau wrote:
> > > This also means that one could install libounit-ocaml-dev_1.0.0-3 (built 
> > > with ocaml 3.08) together with a different version of ocaml, which 
> > > should probably not be possible.
> > 
> > So this should not be possible.
> 
> OK, if the on-disk format does change, I'll agree with you that this is
> not doing the right thing.
> 
> But the OCaml policy is not doing the right thing either.

The ocaml policy was written to handle two transition such as the one we have
here, and we concluded that this is what works best.

> I have no reasno to believe that ounit will be incompatible with OCaml
> 3.09.  In fact, it works fine with 3.07 too.  If somebody has that

Ocaml upstream strongly recomends to rebuild each time there is a new upstream
compiler release. This is why they now also have the stable and the
devleopment branch in CVS. There is no guarantee that code compiled under
ocaml 3.08 will work under 3.09, in fact it most probably wont, and in some
cases smallish source level changes are also needed (like the file position
stuff). Ocaml, contrary to SML, allows for some such changes in order to be
able to evolve better and quicker.

> version of OCaml on their system, they should be able to just grab the
> ounit source package, build it, and get a deb that depends on
> ocaml-base-nox-3.09 or 3.07 or whatever.  The source package should not

Yeah, in theory. The real problem is that the build-depends are there to
control the autobuilders.

> hardcode in those versions except in exceptional circumstances.  In this
> case, I hardcoded >= 3.08 to force the autobuilders to rebuild things in
> the proper order.  I intend to remove that later, since 3.08 is not
> really needed for ounit.

Yeah, i understand, but experience has shown us that this isn't what works
best. Previouslt we had ocaml (>= 3.08), ocaml (<< 3.09) as build-depends.

> Perhaps we can use the shlibs mechanism or something for this?

Yes, that would be nice, still we have trouble in case of you uploading iounit
a day or two before i upload a new ocaml, and then it is well possible that
the different arches will have a iounit built with a different ocaml.

> Incidentally, why do they change the on-disk format so much?

They change it once per release, which is usually once per year in july or so.
They do that to be able to make ocaml evolve, and not be fixed in a standard,
which is also what makes ocaml so great, even if it has some inconveniences.

> And, while we're at it, why do we bother putting the version number in
> the ocaml lib directory if we only support one ocaml version on the
> system at a time?  If we're going to put the version number there, we
> should support multiple versions (like Python does).  Otherwise, having
> the version number there is pointless.

Ah, this was a long question. We had plan for parallel installations, but it
was voted down here as too tedious. Still, this allows us to easily do and
ocaml-3.07 backward compatible package, which we would have done in case coq
would not have worked with 3.08. Also, i had some plan for CVS version of
ocaml, which would go into their own subdirectories.

The main problem being the name of the binaries. And that we didn't really
want to duplicate all those libraries.

Also it allows us to be sure some user is not trying to run randomly installed
stuff from self compilation under ocaml 3.07 with ocaml 3.08.

If you are interested, read the archvies of this list.

> > > ounit will enter testing as soon as the s390 build is uploaded and its 
> > > 10 days are over, because its dependency on ocaml will be satisfied in 
> > > testing). I can file a serious bug in the BTS if necessary, to block 
> > > this migration.
> 
> What exactly is the problem with this?

It is not policy compliant.

Friendly,

Sven Luther



Reply to: