[Debian-ha-maintainers] Bug#519941: Remove Policy permission for packages to modify ld.so.conf

[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.

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 519941 at bugs.debian.org on all discussion.

-- 
Russ Allbery (rra at debian.org)               <http://www.eyrie.org/~eagle/>