On Sun, Jul 28, 2002 at 03:21:46PM -0400, James A. Treacy wrote: > On Sun, Jul 28, 2002 at 02:12:01PM -0300, Henrique de Moraes Holschuh wrote: > > The problem is: rpath looks like the standard, simple answer to > > the problem, while it actually has a lot of side-effects that are > > not really desirable (and not obvious, either). > > Could you elaborate on the side effects? Every time rpath comes up > the discussion is not very productive. It would be nice to have a > place where the pros and cons (and future solutions) are listed so > the discussion can start from some place rational. I'm still convinced that it is fine to use rpath in the following case: - The lib referenced with rpath is in the same package as the binaries that make use of it. - No other binaries in any other package reference the library. (Maybe exception if the other package is closely tied to the first and depends on exactly a particular version.) - The lib is not intended to be used by anyone else. There's no -dev package for it, it is just a convenience lib to avoid that lots of related binaries contain the same code. Let's look at the disadvantages I've heard about so far: - "rpath breaks cross-compilation": It doesn't, at least not inherently. You just need to pay more attention to get things right. rpath will certainly prevent "out of the box" cross-builds of some programs, *but* projects that use automake should be fine. - "You can't substitute different versions of the lib, e.g. debugging versions." True, but not a problem with the scenario I outlined above. - "rpath breaks filesystem moves." Well, this is not a problem with my scenario, since everything is in the same package. I'm not denying that it's a huge problem with "normal" shared libs. - "rpath breaks major lib upgrades such as the libc5 -> libc6". True, but again, I'm only talking about a "convenience library"... So I don't see any reason not to use rpath for things such as the ogle packages. Cheers, Richard -- __ _ |_) /| Richard Atterer | CS student at the Technische | GnuPG key: | \/¯| http://atterer.net | Universität München, Germany | 0x888354F7 ¯ '` ¯
Attachment:
pgpNNNqsD0J8a.pgp
Description: PGP signature