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

Re: status update of ocaml 3.06 testing transition.

Sven Luther wrote:

Hello everybody,
Ok, time for a new weekly status report of the ocaml 3.06 transition.

Well, glibc 2.3.1 is a mess, i guess ome of the RC bugs have even been
closed in -5, but not in the BTS, but i may be wrong, i was hoping that
a new glibc was being uploaded after this WE BSP.

Anyway, i propose here, if we all (well mostly jerom and stefano) agree,
that we postpone the mini-freeze, until such a time that glibc 2.3.1
migrates to testing, and then we start it again.


We also need to take a decision for the libdir move :

 o wait for glibc 2.3.1 to enter testing.

 o choose a date where we can dedicate an hour or so to our packages,
 and do it.


The first option would be safer, but as the sarge release nears, we may
loose the oportunity (and benefit) of it, not that i have any idea of
the sarge release date (there was speak of a 6 month release scheme

Please, don't count on a near release. It is always announced as approaching
but in fact, releases are always delayed.

The second option would be my personal choice, but i need concensus to
go with it.

Notice that it will only hinder new installs, and not cause any problem
when upgrading, as moved packages will only get upgraded when all
installed packages are ready (that is have been rebuilt for
The only point is that i need to get confirmation from the policy people
that the feature of dpkg/apt we use will be policy approved, that is
that apt will prefer a real package over a virtual one anytime there is
such a thing.

Anyway, it will only happen is sarge+1, like any new feature in APT and

Anyway, i will add the new nativecode/bytecode scheme to the next
version of the policy, so maybe it will be good for all of you packaging
ocaml applications (as opposed to libraries) to have a look at the
spamoracle package.

I think we already add a discussion about this and also on -mentors, and
Joey Hess told us that it is not necessarily a problem. It really depends on
the size of applications. This is why I won't use this for cameleon.
I'd propose that not to be mandatory.


Reply to: