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

Re: status update of ocaml 3.06 testing transition.

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

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

So what do you all think of it, should we go with it.

As a side note, i today received a bug report from the hppa autobuilder,
that he had nothing to do with the hppa build of spamoracle. I am
investigating what is going on, but i guess it is a bug/problem with the
hppa autobuilder, as i did not have any hint that the other
non-nativecode autobuilders did fail like this.

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, 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.


Sven Luther

Reply to: