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

Re: it is almost mini-freeze time ...



On Mon, Feb 24, 2003 at 04:42:26PM +0100, Jérôme Marant wrote:
> > Apparently gcc 3.2 now knows how to access 64 bit integers unaligned,
> > while older gcc didn't know how to do this, or maybe it is just the
> > configure script testing which went bad.
> 
> This is good to hear that this has been worked out. Is Xavier going
> to fix this a more clean way?

Yes, altough not immediately, and i will not upload a fixed version
until 3.06-15 has reached testing, i think.

> BTW, I noticed that ocaml 3.06-16 has been rejected by ftp-masters
> and that ocaml-3.06-source was empty in this version. Could you confirm
> that this was a mistake?

Yes, i did wrongly rename the ocaml-source.files, and thus nothing was
copied to the ocaml-source package. This was the reason the package was
rejected, and i have already fixed it. I am waiting to see if 3.06-15
will enter testing without problems, and try to fix some other things
(like the tex stuff i asked some time ago here, but nobody cares about
it). I will also fix the policy stuff Remi submitted, and the unix sleep
patch Goswin sent, mmm, i will probably get the patch xavier did in the
cvs version instead.

I think i will have a look at the ocaml_packaging_policy document to
bring it to par with the changes that we have been doing lately.

Also executables package will be separated in 3 groups :

  o bytecode only, like ledit.

  o native & bytecode versions, like spamoracle.

  o native & custom built bytecode versions, like advi.

A bit of explanation about this latest one. It contains C bindings, and
as thus it doesn't make much sense making it non-custom bytecode, since
we will have to separate the stublibs into a tiny arch: any package
anyway.

What would be nice would be if the ocaml runtime could be put in a
shared library or something for such packages, so that it will not be
copied for every custom executable.

Also, i will write in the policy the decision we did take about the
library dependencies, or maybe use the same tactic as with the ocaml
package.

Friendly,

Sven Luther



Reply to: