[CDRIVER-1057] Install libmongoc-priv.so according to Debian guidelines Created: 24/Dec/15  Updated: 10/Feb/16  Resolved: 10/Feb/16

Status: Closed
Project: C Driver
Component/s: Build, libmongoc
Affects Version/s: None
Fix Version/s: 1.4.0

Type: Bug Priority: Major - P3
Reporter: A. Jesse Jiryu Davis Assignee: A. Jesse Jiryu Davis
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
related to CDRIVER-1015 Package libmongoc-priv for deb Closed

 Description   

Roberto wrote to me:

Debian policy actually
specifically addresses private libraries:

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

Additionally, lintian also complains:

W: libmongoc-priv: package-name-doesnt-match-sonames libmongoc-priv0

I think that it would make sense for you to update the upstream part of
the build system to install the -priv library into something like
/usr/lib/<arch>/mongoc

It would also be a good idea to get the upstream build system to not
install the .so.0 and .so.0.0.0 symlinks if the -priv library really
doesn't have a SONAME.

The policy is here:

https://www.debian.org/doc/debian-policy/ch-files.html#s-libraries

Currently our "debian" branch has some patches to make the package meet Debian's policy. But assuming the Debian policy is a good policy for installing a private runtime library on any Linux distro, we should update our "make install" to match, and then revert the patches in the "debian" branch.



 Comments   
Comment by A. Jesse Jiryu Davis [ 10/Feb/16 ]

Decided against distributing a private-symbols package.

Comment by Remi Collet [ 30/Dec/15 ]

TLDR: I think this debian policy doesn't apply here.

> Shared object files (often .so files) that are not public libraries,

I think this apply to plugin/extension. This is "really" a shared library.

> that is, they are not meant to be linked to by third party
> executables (binaries of other packages),

It is used / linked by third party exec, even if probably only by the php-driver.

Having it installed in a not standard path will means having to use some trick in the php driver to be able to find it (such as RPATH which are forbidden by our Guidelines).

> It would also be a good idea to get the upstream build system to not
> install the .so.0 and .so.0.0.0 symlinks if the -priv library really
> doesn't have a SONAME.

This is a problem (which prevent the dependency detection, which rely on soname).
Perhaps using the libtool -release option (1.3 or 1.3.0 ?) will be a solution if you don't want to track change in it. (so will be mongoc-priv-1.3.so).

Comment by Hannes Magnusson [ 28/Dec/15 ]

Interesting. Sounds reasonable.

Since the -priv isn't strictly part of our public offerings we can make any changes to it, including its install path, but I do suspect it'll break remi packaging of it for fedora (and the php driver).

We should give him a poke when we pick this up to keep him in the loop.

Generated at Wed Feb 07 21:11:26 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.