Re: Hi, packaging mldonkey, rpath + other questions

[Sven LUTHER <luther@dpt-info.u-strasbg.fr>]

On Sun, Sep 08, 2002 at 03:13:19PM +0200, Goswin Brederlow wrote:
> Sven LUTHER <luther@dpt-info.u-strasbg.fr> writes:
> 
> > On Sun, Sep 08, 2002 at 02:34:45AM +0200, Goswin Brederlow wrote:
> > > Sven LUTHER <luther@dpt-info.u-strasbg.fr> writes:
> > > 
> > > > Upstream choose to use rpath, and when i asked on d-m, a huge flameware
> > > > about the usage of rpath followed, which didn't give me a conclusive
> > > > answer in any direction. Upstream mostly ignored my question (well they
> > > > responded, but they like rpath).
> > > 
> > > The problem with rpath, as far as I gathered from various falmes, is
> > > that you depend on the library your build with. Slight changes of the
> > > libraries make the binary unusable, like moving the library or version
> > > changes. Without rpath it still find the library.
> > 
> > Yes, do you want to argue with upstream ?
> 
> No, just fix the debian package of ocaml.

Please, submit a patch about it, and i will consider applying it ...

More seriously, as i have no idea how the rpath stuff works internally,
i am very badly placed about doing this kind of work, don't you think ?

> > > > > 2. mldonkey uses ocamlopt.opt but ocamlopt works as well. Which of the
> > > > > two should I use? Should I build-depend on eigther or conflict with
> > > > > one?
> > > > 
> > > > You should build depend on ocaml-best-compilers, and do a test for the
> > > > presence of ocamlopt.opt before using it.
> > > > 
> > > > Make sure you have a fallback to use bytecode (ocamlc) if ocamlopt is
> > > > not present, or you will get _plenty_ of bug report, as your package
> > > > will _not_ build on m68k, hppa, mips, mipsel and maybe some other i am
> > > > missing.
> > > 
> > > When I do "make byte" I still get an elf binary. Is there a way to
> > > make a binary-all ocaml program? Since its bytecode it seems like a
> > > big waste to have the same bytecode for every arch.
> > 
> > Remove the -custom option.
> 
> Great. I will build a bytecode binary-all and a optimised with
> arch=i386,alpha,...<archs that have ocamlopt>.

Yes, you could also split the package in two binaries, the first one
being a bytecode package, and arch: all, the other being a native code
package and arch: <list of supported arches>.

the second one would divert the binaries of the first one, or something
such.

Friendly,

Sven Luther