Re: ocaml 3.04 packaging issues ...
On Fri, Dec 14, 2001 at 08:44:17PM +0100, Ralf Treinen wrote:
> On Fri, Dec 14, 2001 at 02:14:20PM +0100, Stefano Zacchiroli wrote:
> >
> > [ 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 think this is a good idea.
Ok, let's make such a policy document from the result of discution on this
thread.
> > > Executables :
> > >
> > > We will split the packages into a bytecode one (normal name) and a
> > > nativecode one (adding -native to the name).
>
> I think in most cases the maintainer of a package can decide whether he
> wants to build a bytecode package or a native package. Both have
> advantages and disadvantages:
>
> - bytecode: these would have architecture=all. Advantage: Only one
> package for all architectures. The package could depend on ocaml-run,
> hence the package would be quite small. Since architecture=all the
> autobuilders don't have to touch it.
> Disadvantage: Execution is slower than for native, but this might be
> acceptable for packages that are not critical on execution time
> (like: bibtex2html, ocamlweb).
>
> - native: these would have architecture=any. Advantage: Faster
> execution, hence this would certainly be used for packages like coq.
> Disadvantge: One binary package per architecture,
> and problems with architecture which don't support native code
> compilation. In this case two solutions:
> - compile to byte code with -custom for these architectures (this is
> what we do now)
> - compile to byte code and depend only for these architectures on
> ocaml-run. This seems to me the better solution.
>
> I guess that in most of the cases the package maintainer an decide which
> of the two he wants to apply for his package.
Why not compile both and let the user be the final judge of what he want.
With a clever done diversions tuff, i guess the package maintainer could
strongly hint at one solution he consider best, but leave the user the
possibility to override this, possibly with a debconf dialog or something
such.
True, this makes a bit more work for the packager, and may not be worth it for
some packages (especially the really big ones, like maybe coq), but you can
not think of al the possibilities that can cause the user to choose one or the
other. Imagine a new shiny i386 processor, for which the shipping ocaml has a
broken native code, or something such other unlikely.
That said, compiling the bytecode with -custom for arches without native code
solution is a nice idea i had'nt thought off :)))
BTW, you would need to depend on the ocalk-base package, but also on the
shared stubs libraries of all the non pure ocaml packages you depend on. Maybe
in this case, the -base postfix was ill choosen, or we should split off
libraries with -runtime or something such, including the shared libraries
needed for them.
Also, am i right in thinking that all the shared stub libraries in the ocaml
package got named dllxxx.so ?
They are :
dllbigarray.so dllgraphics.so dllmldbm.so dllnums.so dllstr.so
dllthreads.so dllunix.so and labltk/dlllabltk41.so
And need to be included in the ocaml-base packages .
Does someone know what an rpath is , and if i trully have to worry about the
lintian warnnng about them ?
Friendly,
Sven Luther
Reply to: