[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Packages violating policy 8.2

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 ?

Heisenberg may have slept here...
Manoj Srivastava   <srivasta@debian.org>  <http://www.debian.org/%7Esrivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Reply to: