Re: -rpath with libtool and Debian Linux
On 27 Jan 1999, Alexandre Oliva wrote:
>
> 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.
There are lots of things which users can do which might appear to work,
and then break later.
The user should understand what -rpath is for, and why he should use it,
and when he should use it. As far as I can, it is *not* useful for the
packages which are part of a 'managed' system like Debian. It *is* useful
for users custom-compiling things in custom dirs. Can you tell -rpath to
store the rpath for libmycustomthing.so and not for libc.so? (Not a
rhetorical question - I genuinely don't know the answer). If not, then
I'd suggest that it's rpath that's broken.
> > 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.
In general, it is not useful to have multiple versions of the same
package. In specific cases, it can be.
I don't think that libtool is the right vehicle for you to evangelise your
dislike of packaging systems and the FHS.
> > 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?
You would download the debian package. You would very slightly edit the
rules file (which is like the makefile) to change the prefix passed to
configure. You would then run dpkg-buildpackage. Or simply debian/rules
binary.
If the program wasn't debian packaged at all, you'd read some
documentation on how to create a debian package ;-)
> 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.
These are all worthy ideas.
The idea of a 'fluid file system' or a 'tagged file system' which allows
to mark abitrary subsets of your files with tags (like
'belongs_to_package_x' or 'part_of_debian_version_2.0') is a very worthy
idea.
The idea of extending debian's package system to cope elegantly with
concurrent versions is (probably) a good idea.
However, none of these things are currently available for Linux.
What is available, is a distribution with well-thought (not arbitrary)
structure and standards. A distribution used by many people, although not
as many as RedHat (which has similar standards in most respects anyway).
We have considered library dependencies. We have a working system. It is
reasonably elegant. It is convenient for the users.
It is not the only answer.
Nonetheless, you are refusing to support it.
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: