Bug#66023: [PROPOSAL] Re: Shared libs vs. plugins.
-----BEGIN PGP SIGNED MESSAGE-----
I second this proposal, subject to the typographical and
grammatical corrections included below.
--- policy.sgml.prev Mon Jul 10 11:01:16 2000
+++ policy.sgml Mon Jul 10 11:41:12 2000
@@ -2158,6 +2158,27 @@
+ Shared object files (i.e. <file>libsoname.so</file>) that are
+ not public libraries, that is, they are notmeant to be linked
+ to by third party executables (binaries of other packages),
+ should be installed in the subdirectories of the
+ <file>/usr/lib</file> directory. Such files are exempt from
+ all the rules that govern ordinary shared libraries, except that
+ libraries, except that they must not be installed executable.
+ <footnote>A common example are the so-called ``plug-ins'',
+ internal shared objects that are dynamically loaded by
+ programs using <manref name="dlopen" section="3">.</footnote>
+ 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.
An ever increasing number of packages are using libtool to
do their linking. The latest GNU libtools (>= 1.3a) can take
advantage of the metadata in the installed libtool archive
Many alligators will be slain, but the swamp will remain.
Manoj Srivastava <firstname.lastname@example.org> <http://www.debian.org/%7Esrivasta/>
1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.5 and Gnu Privacy Guard <http://www.gnupg.org/>
-----END PGP SIGNATURE-----