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

Re: [damien.doligez@inria.fr: [Caml-list] Objective Caml release 3.08.4]



Hello,

On Wed, Aug 17, 2005 at 11:06:13AM +0200, Stefano Zacchiroli wrote:
> On Wed, Aug 17, 2005 at 12:30:16AM +0200, Sylvain LE GALL wrote:
> > Maybe i am wrong but i think it is best to keep dh_ocaml out of
> > debhelper. I feel it should be better for made it evolve at will...
> > Maybe it can become a real package ?
> 
> On Tue, Aug 16, 2005 at 08:14:24PM -0400, Eric Cooper wrote:
> > I agree.  I saw that a dh-lisp package (a "debhelper add-on" for
> > Common Lisp) just entered the archive, so there's certainly precedent.
> > 
> > The only downside I see is that OCaml packages that use it will have to
> > build-depend on dh-ocaml in addition to debhelper.  Are there other
> > advantages or disadvantages?
> 
> dh_ocaml has been tought from the beginning to be a part of debhelper as
> it heavily uses debhelper perl library. Keeping it out of the debhelper
> package would mean take care of the compatibility with that underlying
> library; keeping it insider of debhelper would mean that someone else
> (probably JoeyH), would take care of it.
> 
> Note also that dh_ocaml is the debhelper part of the automatic
> dependency handling mechanism, the non-debhelper part is ocaml-md5sums
> which is meant to be keep outside debhelper. I don't think the debhelper
> part of dh_ocaml will change much in the future.
> 
> About the dh-lisp package it is a rather isolate example, all other
> major language-related debhelpers are maintained inside debhelper:
> dh_perl, dh_python. Is a rather common convention.
> 
> I say: just do as everyone else, start shipping it as a part of
> debhelper, if in the future we will encounter out of date issues or slow
> release roundtrip we can move it out.
> 

Ok. I only have a little wish, even if it is a little bit out of scope:

Could dh_ocaml fill a substvars to tell if the package depends or not to
ocamlrun ?

In other word if a package is build on non opt platform, we should
have a depends on ocaml-base-3.08.3.
Here is the script used to do it in mldonkey:

@if [ -x /usr/bin/ocamlopt ] || [ -x /usr/bin/ocamlopt.opt ]; then\
 echo "interpreter:Depends=" >> debian/mldonkey-server.substvars;\
 echo "interpreter:Depends=" >> debian/mldonkey-gui.substvars;\					                dh_strip -a;\
else\
 echo "interpreter:Depends=ocaml-base-3.08.3" >> debian/mldonkey-server.substvars;\
 echo "interpreter:Depends=ocaml-base-3.08.3" >> debian/mldonkey-gui.substvars;\
fi

In fact the best should be to scan every executable to see if it
required ocaml-base...

Regard
Sylvain Le Gall



Reply to: