-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi!
Am 29.01.2005 um 14:48 schrieb Hamish Moffatt:
2. If an admin installs gEDA into /usr/geda(/lib,/bin,etc) they can add /usr/geda/lib to /etc/ld.so.conf. There is no need to use RPATH.
If an admin snstalls geda, on a system, that already has geda installed, e.g. geda-20030223 in /opt/geda-20030223, geda-20030901 in /opt/geda-20030901 and now wants to install geda-20041228 into /opt/geda-20041228, what in your opinion, shod this admin put into /etc/ld.so.conf?
You cannot assume only a single version of geda (or any other non.system package) being installed on a system.
Have you ever tried to let your users use several verions of e.g. X11,
KDE, Gnome �,.. on your system, each user possibly using a different
version at the same time? UNIX is a multi user system and there are
systems out there, where the users need the system running. Installing
a new version of KDE is a major task, that can break a lot of things
the other users are currently using. You may need to be able to install
a new version of the software WITHOUT interrupting the existing service
and allow your users to migrate, when the new software has proven to be
stable and to satisfiy the needs of the users.
You cannot achieve this task if you require the libs to be installed in
the same location, This is what windows does and what is known as DLL
hell. RPATH he the measure to escape this mess. You can install new
software and be sure to not break anything for any user during
installation and later on.
I disagree with all of that. If new library versions are incompatible, they should have a different version number.
How do you know, a new version of a library is compatible? even different compiles produced of the same source code can be incompatible to each other. You only know, that two libs are compatible, if you have carefully checked compatibility.
It is quite acceptable and common to have multiple versions of a library in /usr/lib. For example it is no problem to have /usr/lib/libgeda.so.20 and /usr/lib/libgeda.so.22.
So, who will take care of version numbers? I very much prefere to ande different versions by using different paths. There also is another problem with your versioned aproach: AFAIK, the linker always links to the newest lib. It would be difficult to fix a bug in an older version, since when recompiling later you accidently can ling against the newer lib. You are sure to avoid this mess, when you clearly separate different versions into different filesystem subtrees.
If you install new software, it will either upgrade the existing libraries if they are backwards compatible (hence no effect on the existing installation),
Who do you know, the new files are backwards compatible, prior to installing them?
If you want to install two versions of gEDA, you can put them in different directories and add both to /etc/ld.so.conf. There is no problem as the libraries have different versions.
Since the library version numbers are supplied by the libraries makefiles, this aproach will never catch incompatibilites created e.g. by a new set ob yould tools or different build options.
You haven't convinced me that RPATH solves any problem that is not solved by /etc/ld.so.conf (for admin-installed software) or LD_LIBRARY_PATH (for user-installed software).
Have you ever administered a system for other users? As long as you are the only user, you will hardly have any need to use RPATH to make thing, you cannot achieve by editing /etc/do.so.conf. But as soon as you are resonsable for keeping the system running as aproductivity tool for other users and at se same time keep the softer used up to date without risking the oprations going on, you sool will have no other choise than to use RPATH (or maybe chroot()).
I have done this for several years, I have seen all those problems introduced by careless use of LD_LIBRARY_PATH, I have been fallen on my nose by not cleanly separating newly installed software even after minimal bug fixes of changes, this all long time before linux even supported ELF. I know what I am talking about. I learned to always offer my users a safe way back, when new software is installed. It is an absolute must, when you administer a system for other users.
73, Mario
- -- Mario Klebsch [EMAIL PROTECTED]
PGP-Key available at http://www.klebsch.de/public.key
Fingerprint DSS: EE7C DBCC D9C8 5DC1 D4DB 1483 30CE 9FB2 A047 9CE0
Diffie-Hellman: D447 4ED6 8A10 2C65 C5E5 8B98 9464 53FF 9382 F518
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)
iD8DBQFB+/X9MM6fsqBHnOARAkRuAJ9Xyk971rc+uTHLGe2LvTlKGYNc3wCdE99u ED8UzELBrCgwM7qtycCUWA0= =3fvc -----END PGP SIGNATURE-----
