Bug#636383: debian-policy: 10.2 and others: private libraries may also be multi-arch-ified
Le Tue, Aug 02, 2011 at 10:07:40PM +0200, Julian Andres Klode a écrit :
>
> Policy 10.2 states:
> "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."
>
> Given that multi-arch libraries are in a subdirectory of /usr/lib, this
> section should be changed to account for using a sub-directory of the
> multi-arch library dir, such as /usr/lib/$multiarch/$package instead
> of /usr/lib/$package where useful.
>
> The same thing applies to other cases, so in general, all mentions
> of /usr/lib should probably be replaced by some defined word such
> as "library directory" or something like this.
Dear Julian and everybody,
In my understanding, the multiarch specification currently supports public
libraries only, and therefore does not cover packages shipping plugins in
/usr/lib/$package. Perhaps the change you propose is prematurate ?
About the proposition to replace ‘/usr/lib’ by ‘library directory’, while I
like the idea, I looked for the occurences of ‘/lib’ or ‘/usr/lib’ in the
current Policy and it does not seem to have good targets.
Here are the list of occurences:
$ git grep -B5 -A5 '/lib</file>' policy.sgml
policy.sgml- <heading><tt>ldconfig</tt></heading>
policy.sgml-
policy.sgml- <p>
policy.sgml- Any package installing shared libraries in one of the default
policy.sgml- library directories of the dynamic linker (which are currently
policy.sgml: <file>/usr/lib</file> and <file>/lib</file>) or a directory that is
policy.sgml- listed in <file>/etc/ld.so.conf</file><footnote>
policy.sgml: These are currently <file>/usr/local/lib</file> plus
policy.sgml: directories under <file>/lib</file> and <file>/usr/lib</file>
policy.sgml- matching the multiarch triplet for the system architecture.
policy.sgml- </footnote>
policy.sgml- must use <prgn>ldconfig</prgn> to update the shared library
policy.sgml- system.
policy.sgml- </p>
--
policy.sgml-
policy.sgml- <p>
policy.sgml- It is recommended that supporting files and run-time support
policy.sgml- programs that do not need to be invoked manually by users, but
policy.sgml- are nevertheless required for the package to function, be placed
policy.sgml: (if they are binary) in a subdirectory of <file>/usr/lib</file>,
policy.sgml- preferably under <file>/usr/lib/</file><var>package-name</var>.
policy.sgml- If the program or file is architecture independent, the
policy.sgml- recommendation is for it to be placed in a subdirectory of
policy.sgml- <file>/usr/share</file> instead, preferably under
policy.sgml- <file>/usr/share/</file><var>package-name</var>. Following the
--
policy.sgml- <p>
policy.sgml- Shared object files (often <file>.so</file> files) that are not
policy.sgml- public libraries, that is, they are not meant to be linked
policy.sgml- to by third party executables (binaries of other packages),
policy.sgml- should be installed in subdirectories of the
policy.sgml: <file>/usr/lib</file> directory. Such files are exempt from the
policy.sgml- rules that govern ordinary shared libraries, except that
policy.sgml- they must not be installed executable and should be
policy.sgml- stripped.<footnote>
policy.sgml- A common example are the so-called "plug-ins",
policy.sgml- internal shared objects that are dynamically loaded by
Would you or somebody eles mind if I close this bug report ?
Have a nice week-end,
--
Charles Plessy
Tsurumi, Kanagawa, Japan
Reply to: