Re: status update of ocaml 3.06 testing transition.
Sven Luther wrote:
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.
OK.
Ok ? Ok to which one ?
The last one, for me.
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.
Mmm, you are not in favor of it, right ?
Currently, from the user-friendliness point of view, this is not a proper
solution. The user must not have to install <app>-byte. When he wants
to install <app>, he doesn't care whether it is a bytecode or native
version.
Now, from the disk space point of view, I'd say, like Joey Hess said (and
he has often very accurate judgements), it really depends on the size of
the application. What is good for Coq is not necessarily good for other
applications. Speaking about, Cameleon, it is a set of small applications,
so it is not worth it.
I propose to make it mandadtory only for apps building native code, the
apps doing only bytecode are fine as they are.
The benefit are more than just space saving though, in particular, you
will no more wait for the mipsel or m68k autobuilder to build your
packages, and they will be ready for testing earlier.
As I said above, it really depends.
Also it would enable native code supporting arches to choose either the
native code or the bytecode ones (like advi being broken on ia64 and
native code, due to a too big array, but then maybe i should disable the
native code compiler on ia64 instead).
Also, it is only a little change, and not problem at all for the users.
...
Sure, it would be interresting to see how it scales to other packages
(like cameleon or coq) but i think you will not really need to do any
more work than what you already do to support bytecode build on arches
not supporting the native code compilers.
So, is there another reason for your objection ? If yes, i would really
like to know before i finalize the draft. The only problem i might see
with more complexe package would be about versioned virtual dependencies
not working, but again, this supposes that we really use versioned
depends, not only on libraries but also on app packages. Is this the
case ?
Anyway, there is no way something i write in the policy document will be
able to force you to package things differently than what you want.
Anyway, whatever I say, whatever I prove wrong, you'll modify the policy
anyway.
Reply to: