Re: ocaml 3.04 packaging issues ...
On Fri, Dec 14, 2001 at 03:53:49PM +0100, Stefano Zacchiroli wrote:
> On Fri, Dec 14, 2001 at 03:02:08PM +0100, Sven wrote:
> > > 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)
>
> = he don't use this executable, right?
> He just have not to install that executable.
No, he wants to use bytecode, for whatever reason ...
> > 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.
>
> ok, but where is the advantage?
> Think about the unison package, on architectures that support native
> code it will be compiled as native code, on others as bytecode.
And if i want to use the bytecode version on i386, i have to rebuild it
myself, is that not so ?
You are removing choice from the user by taking this decision out of his hand.
And now suppose that you have written a mozilla pluggin with a ocaml virtual
machine in it. You want to use bytecode executables remotely on those, and
don't want any native code lying around, do you not ?
> > > 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.)
>
> Good point. So we may state (and keep this in mind for an ocaml-policy)
> that a package aimed to be shared between archs, and so installed in
> /usr/share, must be split in -native and bytecode part.
> No need to force this split on all packages, also exception does not
> violate the common shape that I Have in mind for ocaml packages.
Well, yes, ...
We could install all bytecode in /usr/share/ocaml/bin or whatever, and have
the diversion link to it.
> > > 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.
>
> Ooops, I forget that we are talking about ocaml bytecodes that can't be
> stripped, sorry ...
:)))
> Anyway if debugging is a valid reason to have bytecode executable in
> place of native code (where possible), standard exextuables that reside
> in /bin, /usr/bin and so on are not thinked to be debuggable.
I had not thought about this possibility.
> > > 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.
>
> [ still not finding ones ... ]
> [ Also note that this is not polemic, I'm only thinking that to perform
> substantial changes like this one, we at least need valid reasons ]
It was my intention all along, ever since this issue was first discussed here
months ago.
It can wait for after woody though.
BTW, if you don't do it, you loose the main interrest of ocaml-base.
> > 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).
>
> I'm packaging mostly libraries and I provide both flavour on arch that
> support native-code compilation and bytecode only flavour on other
> archs.
> I've only one executable package ocaml related that is ocamlfind, for
> this I provide native-code version where possible and bytecode
> otherwhere.
> The only one other executable package related to ocaml (i.e. written in
> ocaml) I know is unison that do the same as ocamlfind.
>
> > 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 ?
>
> This is surely a wantfull goal.
> But note that all of my libraries have arch: any, and also unison and
> ocamlfind have arch: any.
> This a wantfull goal already obtained.
No, arch: all is not the same as arch: any.
arch: all is a package which can run on all arches, whereas arch: any is a
package that can be built on all arches.
See the difference.
Note, that doing this would position ocaml bytecode against java, tcl/tk and
uncompiled perl. I have no doubt that ocaml bytecode can provide a very strong
alternative for arch independent stuff, and may become a language of choice
for debian, with all of its 8 official arches.
Imagine a apt frontend coded in ocaml bytecode and using lablgtk as interface
:)))
> > 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).
>
> Nice hint, we can ask on ocaml ML for this.
:)))
> > But then, we can make this policy and apply it for woody+1. The important part
> > is to have 3.04 shipping in woody.
>
> Agreed.
Yes, let's wait for after woody for this, unless something important happens
before the freeze, and the freeze is not delayed ad eternam.
I will try to try it out on some lesser used ocaml executable packages, like
mldvi for example.
> P.S. we are already at a 200 lines post, and we are only at the 3rd
> reply ;)
I have cut it down a bit :)))
Friendly,
Sven Luther
Reply to: