Re: Bug#519941: Remove Policy permission for packages to modify ld.so.conf
Hi all,
On Fri, 2009-06-19 at 21:25 -0700, Russ Allbery wrote:
> 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.
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).
> 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.
> 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 €¢ :-)
> 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.
> 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 519941@bugs.debian.org on all discussion.
OK.
Yours,
--
Christian Holm Christensen <cholm@nbi.dk>
Reply to: