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 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
