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

Re: ocaml 3.04 packaging issues ...



On Fri, Dec 14, 2001 at 03:02:08PM +0100, Sven wrote:
> mmm, i thought to use the less strong of the two, i suppose that is suggest,
> will have to check ?

the less strong is suggests.

> > >   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 :)))

good luck :)

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

yes, but rebuilding is less error prone. IMO we can't take the risk to
freeze packages will problems (remember that we, the debian ocamlers,
are a small community and a bug may exists and not be reported for a
long time ...).
I also think that is nice to freeze ocaml packages that are almost
similar in organization, if we want split now we take the risk thas some
libraries will be freezed splitted and some other not.

> > [ 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 ?

don't know, probably on this list :-)
Seriously, when we want to do it we can ask the python guys, I think
anyway that such a policy will not be mandatory as the debian-policy,
but just a set of guidelines for debian ocamlers.

> 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

ok, but on the average I think that none want to do only bytecode
developmente if they can do both development, anyway this is just a
personal opinion.

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

Not sure, currently the autobuilder for arch that does not support
native compilation, e.g. m68k, does not spend additional time while
compiling native code because we test for the existence of ocamlopt.
The only advantage is in a case like this: a package compilation goes
wrong in the native part but successful in bytecode part.
In this case (almost rare) next time the package will be rebuild the
bytecode compilation will be done again, even if the last time is goes
wrong.
But supposing that the two flavour of binary packages (-native and not)
comes from the same source package, we are again in trouble: a source
package that successfull compile only one of its binary packages will
not enter testing!
Obviously I don't want to fork a source package for native and bytecode
flavour of a library.

So where is the compile time gain?

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

Yes, but this guy have not the choice, his binary package of the library
he use contains only the bytecode version. No problem for him. And no
need for him to fork.

> But i agree with you, for libraries it is not all that interresting.

Ok

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

> 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.
If you install unison on a nativecode-compiler-less arch you get the
bytecode, otherwise you get the native-code. Seems to me that this
really fits the user needs.

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

> > 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.
The policy state that a package may support a _compile time_ switch to
enable user debug the executables from the binary package.
So we can put this compile time switch in _source package_ that enable
users to build bytecode binaries even if their arch support native code
compilation.

> > 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 ]

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

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

Cheers.

P.S. we are already at a 200 lines post, and we are only at the 3rd
     reply ;)

-- 
Stefano "Zack" Zacchiroli <zack@cs.unibo.it> ICQ# 33538863
Home Page: http://www.cs.unibo.it/~zacchiro
Undergraduate student of Computer Science @ University of Bologna, Italy
                 - Information wants to be Open -

Attachment: pgpgzGR0uC2Vd.pgp
Description: PGP signature


Reply to: