Re: ocaml 3.04 packaging issues ...
On Fri, Dec 14, 2001 at 02:14:20PM +0100, Stefano Zacchiroli wrote:
> On Fri, Dec 14, 2001 at 01:53:06PM +0100, Sven wrote:
> > o ocaml will recommend ledit
> I prefere "suggests" because a user may only need the ocaml compiler and
> not the toploop, moreover a user may want to use the toploop without
> ledit.
mmm, i thought to use the less strong of the two, i suppose that is suggest,
will have to check ?
> > o i am not sure about splitting off a camlp4 package ?
> the binary package is sized 4Mb so probably is a good idea.
Yes, but i will have to master the multi package stuff first :)))
BTW, camlp4 don't honor the PREFIX makefile variable correctly :((((
> > Beside that we have to decide what is going to happen to the libraries and
> > executable packages, which regard to native/bytecode.
>
> > What do you think of it ?
>
> mainly, that all is stuff have not to be done before freeze.
> This involve a lot of package updates and is better to delay it after
> woody.
mmm, all these packages will have to be rebuilt for ocaml 3.04 anyway.
> [ Minor: probably we have to start thinking about write an
> ocaml-debian-policy like, the python-debian-policy. I.e. a set of
> guidelines for packaging ocaml sw in debian ]
Yes, i was thinking about something such, were does such a policy need to be
sent once it is written ?
> Anyway,
>
> > Libraries :
> >
> > We will split the packages into a bytecode one (normal name) and a
> > nativecode one (adding -native to the name).
> <snip>
> > Not sure if it is trully necessary to split them, what do you all think
> > about it ?
>
> The idea is a bit interesting, but I think we have to find the
> advantages before dive in this substantial set of changes.
The advantage is less for libs than for executables, but basically, this would
have the standard library install the bytecode version (which would be
compiled once for all arch by its maintainer) and he can install the -native
version if available if he wants to do -native developpment. Needless to say
that the -native package will only be installeable on architectures supporting
-native.
> I can't find a lot of advantages: yes the generated packages are smaller
> for archs that support native code compilation, but we are not talking
> about 10megs or so sized packages.
But it downloads the autobuilders + the bytecode version gets available for
all arches immediately, and is immediately considered for testing inclusion.
There is not even need to build it on m68k, one of the slower catching up
libs, since there is no native code support for it. the same goes for some of
the arches without autobuilders or late in building stuff, which don't have a
nativecode support anyway.
> PXP, one of the bigger libraries, doesn't reach the 6Mb size.
The problem is not so much a size problem as a compile time problem, as i see
it.
> Again, a user that install a library probabily want to develop and
> probabily he want do develop both native and bytecode version. So who
> need to install only one of the two flavoues for libraries?
Well, someone using an arch without native code support.
But i agree with you, for libraries it is not all that interresting.
> > Executables :
> >
> > We will split the packages into a bytecode one (normal name) and a
> > nativecode one (adding -native to the name).
>
> this is more interesting because who use an executable probably does not
> need both versions.
Yes, ...
> But again if a user have an arch on which native code compilation is not
> supported he have to use the native code executable.
Unless he chooses not to (and there may be reasons for that)
That said, if native code is supported, then he can just install all the
-native versions of its stuff. You probably would do a -native metapackage
though.
> A user that have the possibility of use the native code executable, why
> want to use the bytecode version?
No reason come to mind right now, but imagine someone sharing its disk between
2 arches (we would need to install in /usr/share then though.)
> Remember that executable in binary package are normally stripped as
> stated in the policy so the debugging possibility on bytecode is not a
> valid reason here.
No, you cannot strip them. Just provide an override for lintian, and exclude
them from stripping in debian/rules.
> So splitting packages in bytecode and native part is nice and elegant,
> but I can't find, at the moment, valid adavantages in doing this split.
Well, what version do you provide right now in your packages ? only the native
code version, and the bytecode version on arches like m68k ? only the bytecode
version (as some do, like ledit i think).
Anyway, the main advantage is in allowing arch: all for the bytecode version,
something which is now possible with ocaml 3.04, and was possible before only
for not -custom bytecode.
We have to discuss though if this is a wantfull goal ?
BTW, there is also a discution i think about ocaml and ocaml.opt, in the
README i think, were it says :
ocamlopt. The ".opt" compilers should run faster than the normal
compilers, especially on large input files, but they may take longer
to start due to increased code size. If compilation times are an issue on
your programs, try the ".opt" compilers to see if they make a
significant difference.
So, this may be a reason to use bytecode even if native code is available, but
i don't know if this generalize to other programs (which presumably are not as
big as ocamlc and ocamlopt).
> If we reach a substantial advantage I will be very happy to enjoy X-Mas
> splitting OCaml packages ;)
:)))
But then, we can make this policy and apply it for woody+1. The important part
is to have 3.04 shipping in woody.
Friendly,
Sven Luther
Reply to: