Manoj Srivastava <[EMAIL PROTECTED]> 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
MfG
Goswin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
