On Tue, May 23, 2006 at 09:42:03PM -0500, Manoj Srivastava wrote:
> On 23 May 2006, Goswin von Brederlow stated:
> > To me it sounds like you are. You provide a shared object file in a
> > public place so other people can link their binaries against
> > it. What else is a shared library? Does it matter if no package in
> > Debian uses it but only other people? I think not. If you intention
> > is to let others link against it then it is a shared library by all
> > means.
>
> It is a shared library, and you are free to link with it --
> but as a developer you must realize that your package may break on
> upgrade, since there is no shared library package, just a single
> combined setools package.
I'm afraid that Goswin is right. If it's not a shared library
package, it shouldn't have anything in /usr/lib; anything else
belongs in /usr/lib/*/ or /usr/share/*/.
> > Policy 10.2:
> >
> > | 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. Such files
> > are exempt from the rules that | govern ordinary shared libraries,
> > except that they must not be | installed executable and should be
> > stripped.
>
> Err, those a plugins, and one generally dlopens them, or
> otherwise manipulates the loader. It certainly does not apply.
FHS 2.3:
# /usr/lib includes object files, libraries, and internal binaries
# that are not intended to be executed directly by users or shell
# scripts.
#
# Applications may use a single subdirectory under /usr/lib. If an
# application uses a subdirectory, all architecture-dependent data
# exclusively used by the application must be placed within that
# subdirectory.
And indeed, most of files I find in /usr/lib/*/ on my system are not
plugins but binary objects of any kind:
* helper programs (most frequent case)
* non-portable data (NetHack levels, etc)
* firmware blobs
* plugins
* private shared libs
^^^^^^^^^^^^^^^^^^^
* scripts, headers, etc which differ between archs
* object files for compilers
It's non-obvious whether a given .so file is loaded with dlopen or
loaded directly, but for example "devscripts" does the latter.
As another example, I've recently made a program with three executables that
share most of their code; quite an usual thing. To save space, the common
parts are placed in a shared library (well, well, .dll ...) that resides in
the program's private dir. On a FHS-compliant system, I can't think of any
place to put such a library other than /usr/lib/$foo/; how is this different
from the case of setools?
I'm not sure if a nobody like me is the right person to correct Manoj,
someone whose name is on the very policy package, but the issue seems to be
pretty clear, at least to me...
Cheers and schtuff,
--
1KB // Microsoft corollary to Hanlon's razor:
// Never attribute to stupidity what can be
// adequately explained by malice.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
