Discussion:
Bug#519941: Remove Policy permission for packages to modify ld.so.conf
Russ Allbery
2009-06-20 04:25:22 UTC
Permalink
In Policy Bug#519941, it was proposed to remove the Policy permission
for packages to modify ld.so.conf in exceptional circumstances. The
implication would be that all packages which do this will need to either
move their libraries into a standard library directory like /usr/lib if
they're really intended to be public or compile with an RPATH setting.
Permission for packages to modify the global library search order to
include a non-standard directory would be removed.

The rationale as stated by Steve Langasek:

| This recommendation needs to be elminated entirely. It is *not* ok
| for packages that provide libraries to stick extra linker paths in the
| global configuration, whether by modifying ld.so.conf or by adding to
| /etc/ld.so.conf.d. Either the libraries provided by the packages are
| meant to be public, in which case they should be installed to the
| standard library path instead of needlessly adding another directory
| that's going to be globally visible anyway; or they should not, and
| the cooperating packages should use rpath instead.
|
| Use of rpath should still be discouraged, but if someone is bound and
| determined to violate the FHS with their library paths in order to
| have private libraries, they should make them really private with
| rpath instead of using this "compromise" solution that takes the worst
| of each approach.

Note that using a separate directory and modifying ld.so.conf does not
usefully resolve name conflicts, since all the libraries end up on the
same global search path anyway and one still has to use RPATH to select
which of two conflictingly-named libraries one wants to load.

This has already recieved the support of six Debian Developers, which is
more than enough to make this change in Policy. However, due to the
broader effects, I wanted to make sure that people were aware of this
discussion and had a chance to review and weigh in. I'm also copying
the maintainers of all packages that apt-file says include files in
/etc/ld.so.conf.d except for libc6 and friends. I have not individually
checked these packages to understand why they include an ld.so.conf.d
fragment, and this doesn't include any packages that modify
/etc/ld.so.conf.

This is the proposed modification to Policy:

--- a/policy.sgml
+++ b/policy.sgml
@@ -7011,17 +7011,6 @@ strip --strip-unneeded <var>your-lib</var>
</p>

<p>
- Packages containing shared libraries that may be linked to
- by other packages' binaries, but which for some
- <em>compelling</em> reason can not be installed in
- <file>/usr/lib</file> directory, may install the shared library
- files in subdirectories of the <file>/usr/lib</file> directory,
- in which case they should arrange to add that directory in
- <file>/etc/ld.so.conf</file> in the package's post-installation
- script, and remove it in the package's post-removal script.
- </p>
-
- <p>
An ever increasing number of packages are using
<prgn>libtool</prgn> to do their linking. The latest GNU
libtools (>= 1.3a) can take advantage of the metadata in the

Please copy ***@bugs.debian.org on all discussion.
--
Russ Allbery (***@debian.org) <http://www.eyrie.org/~eagle/>
Christian Holm Christensen
2009-06-21 19:43:16 UTC
Permalink
Hi all,
Post by Russ Allbery
In Policy Bug#519941, it was proposed to remove the Policy permission
for packages to modify ld.so.conf in exceptional circumstances. The
implication would be that all packages which do this will need to either
move their libraries into a standard library directory like /usr/lib if
they're really intended to be public or compile with an RPATH setting.
Permission for packages to modify the global library search order to
include a non-standard directory would be removed.
| This recommendation needs to be elminated entirely. It is *not* ok
| for packages that provide libraries to stick extra linker paths in the
| global configuration, whether by modifying ld.so.conf or by adding to
| /etc/ld.so.conf.d. Either the libraries provided by the packages are
| meant to be public, in which case they should be installed to the
| standard library path instead of needlessly adding another directory
| that's going to be globally visible anyway; or they should not, and
| the cooperating packages should use rpath instead.
|
| Use of rpath should still be discouraged, but if someone is bound and
| determined to violate the FHS with their library paths in order to
| have private libraries, they should make them really private with
| rpath instead of using this "compromise" solution that takes the worst
| of each approach.
This could be very bad for the root-system package set. ROOT has
libraries named like libMatrix, libPostscript, libPhysics, libMath, and
so on - i.e., very general names. For that reason I moved all the
packages into the subdirectory /usr/lib/root to not cause possible
conflicts. To make this work seamlessly for both the root-system
binaries and user code linked against the libraries, I dump a file
in /etc/ld.so.conf.d/.

For the root-system binaries, there is of course the option to link with
RPATH set. However, I believe that the Policy actually forbids this.

That leaves maintainers no choice but to put libraries in a directory in
the general search path - i.e., /usr/lib. Furthermore, it will be up
to the maintainers to make sure that he/she figures out if other
packages use the same library names and make then `Conflict' against
those packages. This could turn out to be quite some work.

Now, I agree that the names chosen by upstream ROOT developers are poor.
It would have been better to call them something like libRootMatrix,
libRootPostscript, and so on (I can lobby for this, but I fear that it
will have very little effect). One could argue, that one should simply
change the names of the library names in the Debian packages, but
several issues makes this undesirable:

* ROOT sometimes autoloads libraries in response to user input.
This mechanism is partially hard-coded into the sources, and
changing the names in Debian packages only would necessitate a
lot of patching.
* ROOT also sports a kind of Virtual Machine for clusters and Grid
computing. One can simply upload a tar-ball with code and an
automatically generated Makefile to a cluster, and the code will
be built and run on target machine(s). For this to work in a
heterogeneous environment like Grid were many types of Linux's,
Unix's, and what not machines is supposed to contribute, the
names of the libraries must remain the same - since that is
assumed by the generated Makefile (which may not be built on
Debian at all).
Post by Russ Allbery
Note that using a separate directory and modifying ld.so.conf does not
usefully resolve name conflicts, since all the libraries end up on the
same global search path anyway and one still has to use RPATH to select
which of two conflictingly-named libraries one wants to load.
This is, of course, a good point, and the only proper solution to this
is of course to make sure that every single library out there has a
globally unique name (or some other kind of Magic identifier).

However, in the face of `difficult' packages like ROOT or legacy stuff
it might be good to allow for using specific sub-directories. Given
that it is only a few packages that does this, it may not be so bad
after all. Also, since ld.so looks for the so-name which _must_
(according to Policy) contain an interface number it seems unlikely (but
not impossible) that two libraries with the same basename but in two
different directories, has the same so-name.
Post by Russ Allbery
This has already recieved the support of six Debian Developers, which is
more than enough to make this change in Policy. However, due to the
broader effects, I wanted to make sure that people were aware of this
discussion and had a chance to review and weigh in.
This was my 2 €¢ :-)
Post by Russ Allbery
I'm also copying
the maintainers of all packages that apt-file says include files in
/etc/ld.so.conf.d except for libc6 and friends. I have not individually
checked these packages to understand why they include an ld.so.conf.d
fragment, and this doesn't include any packages that modify
/etc/ld.so.conf.
I hope I explained adequately why root-system-common dumps a file
in /etc/ld.so.conf.d - if not, let me know.
Post by Russ Allbery
--- a/policy.sgml
+++ b/policy.sgml
@@ -7011,17 +7011,6 @@ strip --strip-unneeded <var>your-lib</var>
</p>
<p>
- Packages containing shared libraries that may be linked to
- by other packages' binaries, but which for some
- <em>compelling</em> reason can not be installed in
- <file>/usr/lib</file> directory, may install the shared library
- files in subdirectories of the <file>/usr/lib</file> directory,
- in which case they should arrange to add that directory in
- <file>/etc/ld.so.conf</file> in the package's post-installation
- script, and remove it in the package's post-removal script.
- </p>
-
- <p>
An ever increasing number of packages are using
<prgn>libtool</prgn> to do their linking. The latest GNU
libtools (>= 1.3a) can take advantage of the metadata in the
OK.

Yours,
--
Christian Holm Christensen <***@nbi.dk>
Bill Allombert
2009-06-22 10:38:12 UTC
Permalink
Post by Christian Holm Christensen
Hi all,
Post by Russ Allbery
In Policy Bug#519941, it was proposed to remove the Policy permission
for packages to modify ld.so.conf in exceptional circumstances. The
implication would be that all packages which do this will need to either
move their libraries into a standard library directory like /usr/lib if
they're really intended to be public or compile with an RPATH setting.
Permission for packages to modify the global library search order to
include a non-standard directory would be removed.
| This recommendation needs to be elminated entirely. It is *not* ok
| for packages that provide libraries to stick extra linker paths in the
| global configuration, whether by modifying ld.so.conf or by adding to
| /etc/ld.so.conf.d. Either the libraries provided by the packages are
| meant to be public, in which case they should be installed to the
| standard library path instead of needlessly adding another directory
| that's going to be globally visible anyway; or they should not, and
| the cooperating packages should use rpath instead.
|
| Use of rpath should still be discouraged, but if someone is bound and
| determined to violate the FHS with their library paths in order to
| have private libraries, they should make them really private with
| rpath instead of using this "compromise" solution that takes the worst
| of each approach.
This could be very bad for the root-system package set. ROOT has
libraries named like libMatrix, libPostscript, libPhysics, libMath, and
so on - i.e., very general names. For that reason I moved all the
packages into the subdirectory /usr/lib/root to not cause possible
conflicts. To make this work seamlessly for both the root-system
binaries and user code linked against the libraries, I dump a file
in /etc/ld.so.conf.d/.
I understand this issue, but putting libMatrix in /usr/lib/root avoid file
conflict with other package, do not address the problem of library name
conflict at run-time.
Post by Christian Holm Christensen
That leaves maintainers no choice but to put libraries in a directory in
the general search path - i.e., /usr/lib. Furthermore, it will be up
to the maintainers to make sure that he/she figures out if other
packages use the same library names and make then `Conflict' against
those packages. This could turn out to be quite some work.
I cannot see how your scheme avoid such work: your packages still has to
conflict with any other that contains libMatrix to avoid a library name
conflict. Indeed it make it harder because files conflicts are easier to spot
than library name conflict.
Post by Christian Holm Christensen
Now, I agree that the names chosen by upstream ROOT developers are poor.
It would have been better to call them something like libRootMatrix,
libRootPostscript, and so on (I can lobby for this, but I fear that it
will have very little effect). One could argue, that one should simply
change the names of the library names in the Debian packages, but
* ROOT sometimes autoloads libraries in response to user input.
This mechanism is partially hard-coded into the sources, and
changing the names in Debian packages only would necessitate a
lot of patching.
* ROOT also sports a kind of Virtual Machine for clusters and Grid
computing. One can simply upload a tar-ball with code and an
automatically generated Makefile to a cluster, and the code will
be built and run on target machine(s). For this to work in a
heterogeneous environment like Grid were many types of Linux's,
Unix's, and what not machines is supposed to contribute, the
names of the libraries must remain the same - since that is
assumed by the generated Makefile (which may not be built on
Debian at all).
I suggest you try the following:

Put libRootMatrix in /usr/lib and a symlink
/usr/lib/root/libMatrix.so -> /usr/lib/libRootMatrix.so
This way it will be possible to do
gcc -L/usr/lib/root/ -lMatrix
as it is done currently.
Post by Christian Holm Christensen
Post by Russ Allbery
Note that using a separate directory and modifying ld.so.conf does not
usefully resolve name conflicts, since all the libraries end up on the
same global search path anyway and one still has to use RPATH to select
which of two conflictingly-named libraries one wants to load.
This is, of course, a good point, and the only proper solution to this
is of course to make sure that every single library out there has a
globally unique name (or some other kind of Magic identifier).
But this makes your attempt at avoiding conflict quite futile.
Post by Christian Holm Christensen
However, in the face of `difficult' packages like ROOT or legacy stuff
it might be good to allow for using specific sub-directories. Given
that it is only a few packages that does this, it may not be so bad
after all. Also, since ld.so looks for the so-name which _must_
(according to Policy) contain an interface number it seems unlikely (but
not impossible) that two libraries with the same basename but in two
different directories, has the same so-name.
Post by Russ Allbery
This has already recieved the support of six Debian Developers, which is
more than enough to make this change in Policy. However, due to the
broader effects, I wanted to make sure that people were aware of this
discussion and had a chance to review and weigh in.
This was my 2 €¢ :-)
Post by Russ Allbery
I'm also copying
the maintainers of all packages that apt-file says include files in
/etc/ld.so.conf.d except for libc6 and friends. I have not individually
checked these packages to understand why they include an ld.so.conf.d
fragment, and this doesn't include any packages that modify
/etc/ld.so.conf.
I hope I explained adequately why root-system-common dumps a file
in /etc/ld.so.conf.d - if not, let me know.
I do not know. Maybe you could explain in what kind of situation a conflict
is fully prevented by your scheme.

Cheers,
--
Bill. <***@debian.org>

Imagine a large red swirl here.
Darren Salt
2009-06-22 20:42:44 UTC
Permalink
I demand that Bill Allombert may or may not have written...
[snip]
Post by Bill Allombert
ROOT has libraries named like libMatrix, libPostscript, libPhysics,
libMath, and so on - i.e., very general names. For that reason I moved
all the packages into the subdirectory /usr/lib/root to not cause
possible conflicts. To make this work seamlessly for both the
root-system binaries and user code linked against the libraries, I dump a
file in /etc/ld.so.conf.d/.
I understand this issue, but putting libMatrix in /usr/lib/root avoid file
conflict with other package, do not address the problem of library name
conflict at run-time.
Perhaps this?

* Install the binaries in /usr/lib/root.
* Provide wrappers such as the following in /usr/bin:

#! /bin/sh -e
export LD_LIBRARY_PATH=/usr/lib/root"${LD_LIBRARY_PATH:+:}$LD_LIBRARY_PATH}"
exec /usr/lib/root/"$(basename "$0")" "$@"

[snip]
--
| Darren Salt | linux at youmustbejoking | nr. Ashington, | Doon
| Debian GNU/Linux | or ds ,demon,co,uk | Northumberland | Army
| + RIPA NOTICE: NO CONSENT GIVEN FOR INTERCEPTION OF MESSAGE TRANSMISSION

The only way to make something foolproof is to keep it away from fools.
Russ Allbery
2009-06-22 22:56:47 UTC
Permalink
Post by Darren Salt
Perhaps this?
* Install the binaries in /usr/lib/root.
#! /bin/sh -e
export LD_LIBRARY_PATH=/usr/lib/root"${LD_LIBRARY_PATH:+:}$LD_LIBRARY_PATH}"
It's generally better to just set RPATH when building the binaries for
that case.
--
Russ Allbery (***@debian.org) <http://www.eyrie.org/~eagle/>
Christian Holm Christensen
2009-06-22 12:41:09 UTC
Permalink
Hi again,

Let me first clear up a confusion:

I agree that putting a library in a sub-directory does not disambiguate
ld.so searches. If libFoo.so.1 exists in both /usr/lib/bar
and /usr/lib/baz and both these directories are in the ld.so search path
(one way or another), then there is an ambiguity.
Post by Bill Allombert
Post by Christian Holm Christensen
Hi all,
...
Post by Bill Allombert
Post by Christian Holm Christensen
Post by Russ Allbery
| Use of rpath should still be discouraged, but if someone is bound and
| determined to violate the FHS with their library paths in order to
| have private libraries, they should make them really private with
| rpath instead of using this "compromise" solution that takes the worst
| of each approach.
This could be very bad for the root-system package set. ROOT has
libraries named like libMatrix, libPostscript, libPhysics, libMath, and
so on - i.e., very general names. For that reason I moved all the
packages into the subdirectory /usr/lib/root to not cause possible
conflicts. To make this work seamlessly for both the root-system
binaries and user code linked against the libraries, I dump a file
in /etc/ld.so.conf.d/.
I understand this issue, but putting libMatrix in /usr/lib/root avoid file
conflict with other package, do not address the problem of library name
conflict at run-time.
Agreed. Suppose you have packages bar and baz, both of which contain
/usr/lib/libfoo.so.1. If bar "Conflict"s with baz or vice versa, then
both of them cannot be installed at the same time, and there will only
be one possible /usr/lib/libfoo.so.1 on the system. Now suppose the
package gnus comes along, which also provides /usr/lib/libfoo.so.1, then
both bar and baz needs to "Conflict" with gnus, or gnus has to conflict
with bar and baz. I guess it is an N! problem.
Post by Bill Allombert
Post by Christian Holm Christensen
That leaves maintainers no choice but to put libraries in a directory in
the general search path - i.e., /usr/lib. Furthermore, it will be up
to the maintainers to make sure that he/she figures out if other
packages use the same library names and make then `Conflict' against
those packages. This could turn out to be quite some work.
I cannot see how your scheme avoid such work: your packages still has to
conflict with any other that contains libMatrix to avoid a library name
conflict.
Yes and no. If bar and baz had put libfoo.so.1 in /usr/lib/bar
and /usr/lib/baz respectively, one could at least install both packages
at the same time without any conflict. If a user needed to use baz's
libfoo.so.1, he or she could use an explicit LD_LIBRARY_PATH or
LD_PRELOAD to override the cache/system settings of ld.so. In that way,
the user at least have a choice.
Post by Bill Allombert
Indeed it make it harder because files conflicts are easier to spot
than library name conflict.
Agreed. Spotting all possible file conflicts does however require
downloading a huge Contents.arch.gz file and grep'ing for all possible
names. If this could be automated a little, it would be nice.
Post by Bill Allombert
Post by Christian Holm Christensen
Now, I agree that the names chosen by upstream ROOT developers are poor.
It would have been better to call them something like libRootMatrix,
libRootPostscript, and so on (I can lobby for this, but I fear that it
will have very little effect). One could argue, that one should simply
change the names of the library names in the Debian packages, but
* ROOT sometimes autoloads libraries in response to user input.
This mechanism is partially hard-coded into the sources, and
changing the names in Debian packages only would necessitate a
lot of patching.
* ROOT also sports a kind of Virtual Machine for clusters and Grid
computing. One can simply upload a tar-ball with code and an
automatically generated Makefile to a cluster, and the code will
be built and run on target machine(s). For this to work in a
heterogeneous environment like Grid were many types of Linux's,
Unix's, and what not machines is supposed to contribute, the
names of the libraries must remain the same - since that is
assumed by the generated Makefile (which may not be built on
Debian at all).
Put libRootMatrix in /usr/lib and a symlink
/usr/lib/root/libMatrix.so -> /usr/lib/libRootMatrix.so
This way it will be possible to do
gcc -L/usr/lib/root/ -lMatrix
as it is done currently.
Ah, but that does not solve the issue. If you do this, the so-name
referenced in the application/shared library will be libRootMatrix which
may not exist on another machine. Kind of tricky this is. Apart from
that, making symlinks all over the place isn't really that nice (I know
I do make a lot already - but I'm trying to convince upstream a better
solution).
Post by Bill Allombert
Post by Christian Holm Christensen
Post by Russ Allbery
Note that using a separate directory and modifying ld.so.conf does not
usefully resolve name conflicts, since all the libraries end up on the
same global search path anyway and one still has to use RPATH to select
which of two conflictingly-named libraries one wants to load.
This is, of course, a good point, and the only proper solution to this
is of course to make sure that every single library out there has a
globally unique name (or some other kind of Magic identifier).
But this makes your attempt at avoiding conflict quite futile.
Agreed, as I said above.
Post by Bill Allombert
Post by Christian Holm Christensen
I hope I explained adequately why root-system-common dumps a file
in /etc/ld.so.conf.d - if not, let me know.
I do not know. Maybe you could explain in what kind of situation a conflict
is fully prevented by your scheme.
It isn't - as I said.

For the next set of ROOT packages, I will put all libraries in /usr/lib
directly, while I will leave plug-ins in /usr/lib/root/X.Y/ (they are
not meant to be public even though many ROOT users think they are). As
far as I can tell no other packages supply any library name that
conflicts with the ROOT library names at the moment, so I guess I'll be
stacking a claim on that namespace :-)

Yours,
--
___ | Christian Holm Christensen
|_| | -------------------------------------------------------------
| | Address: Sankt Hansgade 23, 4 Phone: (+45) 35 35 96 91
_| DK-2200 Copenhagen N Cell: (+45) 24 61 85 91
_| Denmark Office: (+45) 353 25 447
____| Email: ***@nbi.dk Web: http://cern.ch/cholm
| |
Bill Allombert
2009-06-23 13:35:03 UTC
Permalink
Post by Christian Holm Christensen
Yes and no. If bar and baz had put libfoo.so.1 in /usr/lib/bar
and /usr/lib/baz respectively, one could at least install both packages
at the same time without any conflict. If a user needed to use baz's
libfoo.so.1, he or she could use an explicit LD_LIBRARY_PATH or
LD_PRELOAD to override the cache/system settings of ld.so. In that way,
the user at least have a choice.
Agreed, though if both packages add /usr/lib/bar(baz) to ld.so
at installation times and try to run some programs, they might fail to
install.
Post by Christian Holm Christensen
Post by Bill Allombert
Indeed it make it harder because files conflicts are easier to spot
than library name conflict.
Agreed. Spotting all possible file conflicts does however require
downloading a huge Contents.arch.gz file and grep'ing for all possible
names. If this could be automated a little, it would be nice.
I does this check at times (for all the archive) and report bugs...

At least dpkg will report an error when this occurs.
Post by Christian Holm Christensen
Post by Bill Allombert
Post by Christian Holm Christensen
Now, I agree that the names chosen by upstream ROOT developers are poor.
It would have been better to call them something like libRootMatrix,
libRootPostscript, and so on (I can lobby for this, but I fear that it
will have very little effect). One could argue, that one should simply
change the names of the library names in the Debian packages, but
* ROOT sometimes autoloads libraries in response to user input.
This mechanism is partially hard-coded into the sources, and
changing the names in Debian packages only would necessitate a
lot of patching.
* ROOT also sports a kind of Virtual Machine for clusters and Grid
computing. One can simply upload a tar-ball with code and an
automatically generated Makefile to a cluster, and the code will
be built and run on target machine(s). For this to work in a
heterogeneous environment like Grid were many types of Linux's,
Unix's, and what not machines is supposed to contribute, the
names of the libraries must remain the same - since that is
assumed by the generated Makefile (which may not be built on
Debian at all).
Put libRootMatrix in /usr/lib and a symlink
/usr/lib/root/libMatrix.so -> /usr/lib/libRootMatrix.so
This way it will be possible to do
gcc -L/usr/lib/root/ -lMatrix
as it is done currently.
Ah, but that does not solve the issue. If you do this, the so-name
referenced in the application/shared library will be libRootMatrix which
may not exist on another machine. Kind of tricky this is. Apart from
that, making symlinks all over the place isn't really that nice (I know
I do make a lot already - but I'm trying to convince upstream a better
solution).
I agree, though I think my solution adresses your two * points above.
Do you really have strong binary compatibility requirement between a Debian
machine and a non-Debian one ? Given the mess root shared libraries are,
this seems a difficult proposition.
Post by Christian Holm Christensen
Post by Bill Allombert
Post by Christian Holm Christensen
I hope I explained adequately why root-system-common dumps a file
in /etc/ld.so.conf.d - if not, let me know.
I do not know. Maybe you could explain in what kind of situation a conflict
is fully prevented by your scheme.
It isn't - as I said.
For the next set of ROOT packages, I will put all libraries in /usr/lib
directly, while I will leave plug-ins in /usr/lib/root/X.Y/ (they are
not meant to be public even though many ROOT users think they are). As
far as I can tell no other packages supply any library name that
conflicts with the ROOT library names at the moment, so I guess I'll be
stacking a claim on that namespace :-)
I agree it will be better than the current arrangement.

Cheers,
--
Bill. <***@debian.org>

Imagine a large red swirl here.
Steve Langasek
2009-06-26 21:47:26 UTC
Permalink
Post by Christian Holm Christensen
Post by Bill Allombert
I understand this issue, but putting libMatrix in /usr/lib/root avoid file
conflict with other package, do not address the problem of library name
conflict at run-time.
Agreed. Suppose you have packages bar and baz, both of which contain
/usr/lib/libfoo.so.1. If bar "Conflict"s with baz or vice versa, then
both of them cannot be installed at the same time, and there will only
be one possible /usr/lib/libfoo.so.1 on the system. Now suppose the
package gnus comes along, which also provides /usr/lib/libfoo.so.1, then
both bar and baz needs to "Conflict" with gnus, or gnus has to conflict
with bar and baz. I guess it is an N! problem.
If all of these libfoo.so.1 files implement the same interface, why does
someone ever need to have more than one of them installed at a time? In
that case, Conflicts: is reasonable; and you can use a mutually agreed-upon
virtual package (Conflicts/Replaces/Provides) to solve the N! problem.

If they don't implement the same interface, then why are they using the same
name? In this case they should solve the conflicts by using distinguished
sonames, not merely different paths for the library, to avoid accidental
library path collisions.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
***@ubuntu.com ***@debian.org
Russ Allbery
2009-06-22 15:32:53 UTC
Permalink
Post by Christian Holm Christensen
This could be very bad for the root-system package set. ROOT has
libraries named like libMatrix, libPostscript, libPhysics, libMath, and
so on - i.e., very general names. For that reason I moved all the
packages into the subdirectory /usr/lib/root to not cause possible
conflicts. To make this work seamlessly for both the root-system
binaries and user code linked against the libraries, I dump a file
in /etc/ld.so.conf.d/.
For the root-system binaries, there is of course the option to link with
RPATH set. However, I believe that the Policy actually forbids this.
That leaves maintainers no choice but to put libraries in a directory in
the general search path - i.e., /usr/lib.
Which is what you already did by adding the directory to ld.so.conf, no?
Post by Christian Holm Christensen
Furthermore, it will be up to the maintainers to make sure that he/she
figures out if other packages use the same library names and make then
`Conflict' against those packages. This could turn out to be quite
some work.
Except that moving them to a different directory doesn't really avoid
this if you have a fully conflicting library with the same version. If
you installed both root-system and another library with the same name at
the same time now, you'd get one or the other depending on the
ld.so.conf order, leading to unpredictable results, segfaults, and so
forth. dpkg refusing to install both at the same time is actually
cleaner, I think.

It also shouldn't be that much work to use apt-file to watch for
conflicting packages. You should be able to set up a script that uses
apt-file and runs once a month or so to look for new conflicts.
Post by Christian Holm Christensen
This is, of course, a good point, and the only proper solution to this
is of course to make sure that every single library out there has a
globally unique name (or some other kind of Magic identifier).
However, in the face of `difficult' packages like ROOT or legacy stuff
it might be good to allow for using specific sub-directories. Given
that it is only a few packages that does this, it may not be so bad
after all. Also, since ld.so looks for the so-name which _must_
(according to Policy) contain an interface number it seems unlikely (but
not impossible) that two libraries with the same basename but in two
different directories, has the same so-name.
The same thing applies to libraries installed in the same directory,
such as both installed in /usr/lib, although the dev packages would
have to conflict. Heimdal and libkrb5-3 both install a /usr/lib/libkrb5
shared library, for instance, but with different SONAMEs, so just the
development packages have to conflict.
--
Russ Allbery (***@debian.org) <http://www.eyrie.org/~eagle/>
Kurt Roeckx
2009-06-26 14:59:26 UTC
Permalink
Post by Christian Holm Christensen
This could be very bad for the root-system package set. ROOT has
libraries named like libMatrix, libPostscript, libPhysics, libMath, and
so on - i.e., very general names. For that reason I moved all the
packages into the subdirectory /usr/lib/root to not cause possible
conflicts. To make this work seamlessly for both the root-system
binaries and user code linked against the libraries, I dump a file
in /etc/ld.so.conf.d/.
For the root-system binaries, there is of course the option to link with
RPATH set. However, I believe that the Policy actually forbids this.
I see no reason why policy should forbid rpath's for that case.
What we don't want is an rpath for "/usr/lib". But an rpath
for "/usr/lib/root" would be the right thing to do for
libraries/binaries from the root system.


Kurt
Russ Allbery
2009-06-26 16:41:50 UTC
Permalink
This could be very bad for the root-system package set. ROOT has
libraries named like libMatrix, libPostscript, libPhysics, libMath,
and so on - i.e., very general names. For that reason I moved all
the packages into the subdirectory /usr/lib/root to not cause
possible conflicts. To make this work seamlessly for both the
root-system binaries and user code linked against the libraries, I
dump a file in /etc/ld.so.conf.d/.
For the root-system binaries, there is of course the option to link
with RPATH set. However, I believe that the Policy actually forbids
this.
I see no reason why policy should forbid rpath's for that case. What
we don't want is an rpath for "/usr/lib". But an rpath for
"/usr/lib/root" would be the right thing to do for libraries/binaries
from the root system.
Currently, I don't think Policy says anything about RPATH. It does say:

Shared object files (often `.so' files) that are not public
libraries, that is, they are not meant to be linked to by third
party executables (binaries of other packages), should be installed
in subdirectories of the `/usr/lib' directory. Such files are
exempt from the rules that govern ordinary shared libraries, except
that they must not be installed executable and should be
stripped.[5]

Perhaps that's not quite the definition of "not public" we want?
--
Russ Allbery (***@debian.org) <http://www.eyrie.org/~eagle/>
Steve Langasek
2009-06-26 22:03:46 UTC
Permalink
Post by Kurt Roeckx
Post by Christian Holm Christensen
For the root-system binaries, there is of course the option to link with
RPATH set. However, I believe that the Policy actually forbids this.
I see no reason why policy should forbid rpath's for that case.
For the standard reason that rpath is bad: it breaks when library paths
change, as will hopefully happen soon with multiarch. :)
Post by Kurt Roeckx
What we don't want is an rpath for "/usr/lib". But an rpath
for "/usr/lib/root" would be the right thing to do for
libraries/binaries from the root system.
Yes, it's the least-bad option in this case, in spite of the knock-on
problems.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
***@ubuntu.com ***@debian.org
Continue reading on narkive:
Loading...