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

Re: Packages violating policy 8.2

Manoj Srivastava <srivasta@debian.org> writes:

>         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.

I agree with "section 8.2 is for people who want to provide a shared
library for other packages" but not the rest. As soon as you have a
cross source package dependency you will have upgrade problems if the
shared library is not in a shared library package that follows 8.2.
The big fat state reason why there is an 8.2.

>> 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.

You forgot the next paragraph. An application in the FHS would be one
or more packages in debian. But then again it says: _if_ you have a
subdir then...

>> 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 ?

Usualy that is done with rpath, as ugly as that is. Modifying
/etc/ld.so.conf is never done. Setting LD_LIBRARY_PATH is another
option as is using the full path in dlopen (though that is usualy only
used on plugins).

>         manoj


Reply to: