Re: ocaml 3.04 packaging issues ...
Sorry for having been offline the last days ...
On Sat, Dec 15, 2001 at 03:17:14AM +0100, Sven wrote:
> On Fri, Dec 14, 2001 at 08:44:17PM +0100, Ralf Treinen wrote:
> >
> > 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.
I think that providing two versions for every application package is
in many cases an overkill. It will double the number of packages
written in ocaml (which aren't too many for the moment, but who knows).
While I aggree that there are cases where it makes sense to provide
both I tend to say that in most cases the package maintainer can make
a decision whether he wants to provide a bc or native package. If
execution speed does not degrade too much then I would consider to
build my package as bc.
>
> 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.
Well, in some sense this is the point of building a software
distribution. You as a package maintainer have to decide which are the
build options that make sense for your typical users. There is a
tradeoff between customizing everything yourself and using a standard.
Thinking of bibtex2html, for example: Bibtex data bases are restricted
in size to <= 5000 entries (or something like this) anyway (this is a
restriction of the bibtex program). If a bytecode bibtex2html runs
reasonably on this then I will build the package in bytecode. True, a
user might use the bibtex format to build some other application data
base which has nothing to do with bibtex, and then run bibtex2html on
it. If there are 1 or 2 users with such special needs then too bad for
them, I cannot build a custom package just for them.
> Imagine a new shiny i386 processor, for which the shipping ocaml has a
> broken native code, or something such other unlikely.
This is of course different. If one of native or bc is broken on one
architecture then the maintainer should be able to use the other option
on this architecture. BTW, Judicael Courant is curently implementing
for the coq package a mechanism that attempts to build the package in
native, and to rebuild in bc if the native compilation fails.
Having said that I agree that thre might be cases where it make sense to
build both a native and a bc package. However, I would like to have the
maintainer decide what is sensible in his case.
Remains the interesting
question on how to build packages that come in a native and in a bc
version. Sven suggested using diversions, there is also the possibility
of alternatives. I have never used any of them in my packages, and I
don't know which of them to prefer. Alternatives seem to be less trouble
to use, though.
One could imagine another possibility for providing for both of a native
and a bc executable: one could imagine a directory "/usr/share/bin"
which contains architecture independent executables - like ocaml bc,
shell scripts, perl (!) scripts, ... If this directory comes after /bin
and /usr/bin in a users path then he will automatically give preference
to a native version in /usr/bin to a bc version in /usr/share/bin.
The FHS does not mention a directory /usr/share/bin. Maybe I will ask on
debian-devel what people think of it.
> 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.
Does version 3.04-2 of the runtime package contain the libraries that
are used by the runtime system? bc packages loose a lot of their
potential advantages when a user needs to install the ocaml development
package to run them.
Best seasonal greetings to all of you -Ralf.
Reply to: