On 25 May 2006, Adam Borowski told this:
> 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/*/.
Why is it that you think so? /usr/lib/ is for shared
libraries, but I can't see anything that says only shared library
packages contain shared libs.
I would say, off hand, that section 8.2 is for people who want
to provide a shared library for other packages, with a stable ABI,
and a development package to facilitate linking to their
library. There are certain hoops we must jump in order to not break
packages whenever the share library package source changes.
> 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.
Thje FHS says nothing about packages, so as long as shared
libs go into /usr/lib, I don't think the FHS sheds any other light on
the topic.
> 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?
Then any time you run the program, the loader needs to be told
of the private directory, or you need to explicitly dlopen them. Why
not put them in /usr/lib directly? especially if doing so otherwise
would require major hacking of the upstream build system, and make
Debian deviate from other distributions.
I could add a subdir, and play with /etc/ld.so.conf in the
maintainer scripts -- and deviate us from other distributions -- but
to what end? How does it benefit the users if the libraries in
question all live in /usr/lib rather than /usr/lib/setools ?
manoj
--
Heisenberg may have slept here...
Manoj Srivastava <[EMAIL PROTECTED]> <http://www.debian.org/%7Esrivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
