Re: Hi, packaging mldonkey, rpath + other questions

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

On Mon, Sep 09, 2002 at 12:16:22PM +0200, Goswin Brederlow wrote:
> Sven LUTHER <luther@dpt-info.u-strasbg.fr> writes:
> 
> > 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 ?
> 
> Same here. I greped the source and it seems rpath is only in 3 files,
> only of them source. rpath is in the configure stuff, so there might
> be a compiletime option to turn it off already.

There is the -rpath option to the ocamlc compiler which knows about
this.

> Its low on my todo list. I will ignore it till something breaks,
> someone complains or I get bored.

Well, keep in mind that the bytecode library generation is a complex
thing, that the -rpath may break other things that are not evident at
first, and that, if possible, we should not change our stuff very much
from the upstream version. Mostly they are much more competent than us
on this, and know more exactly about it. If you want to remove the
-rpath, then we should get at lest their agreement or opinion on this.

> > the second one would divert the binaries of the first one, or something
> > such.
> 
> mldonkey is a start script (doing a cd and starting the real mldonkey),
> the mldonkey and 2 small example files. I think packages that conflict
> would be good enough. Making them coexist or divert each other
> probably uses more space than duplicate example files and startup
> script. I don't think someone wants the bytecompile and optimised on
> the same system.

Ok, it's up to you.

(But if they divert, then it is easier to make speed comparison between
them :)))

Friendly,

Sven Luther
> 
> MfG
>         Goswin