Re: -rpath with libtool and Debian Linux
On Jan 27, 1999, Jules Bean <jmlb2@hermes.cam.ac.uk> wrote:
> On 27 Jan 1999, Alexandre Oliva wrote:
>> Except that, if you replace the library with an incompatible one, you
>> *are* breaking the contract.
> We don't replace libraries with incompatible ones.
Oh yes, you are.
> 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.
Except that it can't do that if the user happened to use a switch that
was available, and its use didn't trigger any blinking light saying
that this would cause any future upgrade he might do to silently break
his program.
If you do want to be able to freely move libraries around, -rpath must
be forbidden. If -rpath is available for users, you can't move
libraries around and expect things to work.
> Who cares where they are stored?
The user who used -rpath?
> Actually, we do care where they are stored.
Ah! And that's where the potential conflict comes from.
> My point is, that it doesn't matter if the new library is in the location
> the old library used to occupy.
It may matter for the user who used -rpath.
> Our linker knows which is which.
Not always. Or maybe you can fix your linker to do the right thing
even if the user inadvertently (incorrectly, in your terms) specified
-rpath.
> 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.
And that's the very reason why I've never been able to adopt any of
the available packaging systems: the only way to keep multiple
working versions is to use a separate directory for each version of
each package.
>> 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 ;-)
Jeez!, I was sure I had added a smiley after that last sentence.
Sorry about that...
> If you want to test one version, you simply run it with
> ./configure --prefix /home/me/nicepackage
But isn't this exactly what the packaging systems are trying to avoid,
i.e., that people have to compile systems on their own? And then, how
could I make sure that my test build works exactly as the pre-compiled
upgrade, so that I could use the packaging system for the update?
This is something that I feel that should be taken care of by the
existing GNU/Linux distributions. In fact, I've got a bunch of ideas
that I'll probably never find time to implement :-( about how to
maintain multiple versions of packages installed and allowing each
user to select which version he wants to use, either by explicit
version number or by tags such as `stable', `test', `old', etc, tags
that are determined by the system manager when he installs the
package.
--
Alexandre Oliva http://www.dcc.unicamp.br/~oliva aoliva@{acm.org}
oliva@{dcc.unicamp.br,gnu.org,egcs.cygnus.com,samba.org}
Universidade Estadual de Campinas, SP, Brasil
Reply to: