Re: -rpath with libtool and Debian Linux
On 27 Jan 1999, Alexandre Oliva wrote:
>
> > The contract simply states that the library will be found. Which
> > library is used can be determined by the linker.
>
> Except that, if you replace the library with an incompatible one, you
> *are* breaking the contract.
We don't replace libraries with incompatible ones.
We bring in new libraries, which are incompatible. We keep the old ones,
which are compatible. Our linker knows how to tell which is which. Who
cares where they are stored? Actually, we do care where they are stored.
My point is, that it doesn't matter if the new library is in the location
the old library used to occupy. Our linker knows which is which.
>
> Furthermore, there's no reason to assume that the user will *not* have
> used -rpath himself, so moving libraries does have a potential for
> breaking user programs, therefore it should best be avoided.
This is a valid point. It is my feeling that -rpath should not be used
for libraries in the 'standard' paths, which allows them to move (which is
a useful feature). It is reasonable to use it for libraries in unusual
places (another useful feature).
> I think a solution that is not general is not a good solution. Since
> the solution of moving shared libraries around has the potential of
> causing problems, if I were you, I'd work harder to try to find a
> complete solution (which I happen to have already suggested) instead
> of trying to blame libtool or other users for doing things that are
> perfectly correct, but not in the way that would let you replace
> incompatible libraries.
I agree with your suggested solution, which amounted to more complex
understanding and use of inter-library dependencies by the tools.
However, I don't have the expertise to implement this. And I disagree
with you (strongly) about the correct use of the existing system.
>
> > Our distribution cares greatly about separating packages from each other.
>
> Not from the point of view of the end user. When they want to find a
> tool, they may `ls /usr/bin /usr/local/bin' and will be presented
> *thousands* of files. I'd rather have a classification system in
> which I could have links (or similar) to all programs in a common
> directory, but in which I could search for programs by subject. I'd
> like to have development tools such as compilers in one directory,
> text writing tools such as word processors and text editors in
> another, system administration utilities in another, and so on.
> Additionally, I'd like to be able to keep multiple versions of a
> package installed, and the only way I could do that is by installing
> each version in a separate directory, and selecting which version to
> use via soft-links in the directory that happens to be in my PATH.
>
We do have a classification system. And we don't use the filesystem for
it. We have lists of packages, with descriptions.
We even support separate versions of software, to some extent, although
I'd agree completely that our support in this area is not what it might
be.
> How does the current packaging system allows me to test one version of
> a package while other users of the same host are running a stable
> version of that tool? Or are the GNU/Linux distributions all moving
> towards the Micro$oft model of single-user workstations?
Of course not ;-)
If you want to test one version, you simply run it with
./configure --prefix /home/me/nicepackage
or whatever. But you knew that.
Jules
/----------------+-------------------------------+---------------------\
| Jelibean aka | jules@jellybean.co.uk | 6 Evelyn Rd |
| Jules aka | jules@debian.org | Richmond, Surrey |
| Julian Bean | jmlb2@hermes.cam.ac.uk | TW9 2TF *UK* |
+----------------+-------------------------------+---------------------+
| War doesn't demonstrate who's right... just who's left. |
| When privacy is outlawed... only the outlaws have privacy. |
\----------------------------------------------------------------------/
Reply to: