Wrong name, soname for libsystemd-shared-231.so #3810

tpgxyz · 2016-07-26T13:59:26Z

Submission type

Bug report
[X ] Request for enhancement (RFE)

NOTE: Do not submit anything other than bug reports or RFEs via the issue tracker!

systemd version the issue has been seen with

231

NOTE: Do not submit bug reports about anything but the two most recently released systemd versions upstream!

Used distribution

OpenMandriva Lx

In case of bug report: Expected behaviour you didn't see

…

In case of bug report: Unexpected behaviour you saw

A libsystemd-shared-231.so has been intorduced. Intentions are fine and needed. Problem occurs with packaging on distributions that "proctect shared object major".

For example, each library is packaged separately libfoobar1.x86_64.rpm
In case of libsystemd-shared-231.so RPM treats this as a "development" library because name and soname does not fit in old scheme libfoobar%{api}.so.%{major}.%{minor}*

Desired change will be to rename libsystemd-shared-231.so to libsystemd-shared.so.231

In case of bug report: Steps to reproduce the problem

…

martinpitt · 2016-07-26T14:16:48Z

I recommend to not package the internal library separately. For Debian and Ubuntu at least it works fine to just put it into the systemd package. Nothing else than systemd's own binaries can link against it anyway.

martinpitt · 2016-07-26T14:17:09Z

Desired change will be to rename libsystemd-shared-231.so to libsystemd-shared.so.231

No, this is absolutely wrong. This is not what SONAMEs do/are.

mbiebl · 2016-07-26T14:23:39Z

We intentionally used libtool's -release flag for libsystemd-shared to make it clear that this is not a stable interface and should not be treated as public library.

poettering · 2016-07-26T14:45:24Z

@tpgxyz note that we place this library in a private systemd-specific subdir of $(libdir), not in $(libdir) for a reason: so that it does not appear in the usual search path. If you distro requires you to package all libs in separate RPMs, then I'd argue this doesn't apply here, as this is by all mechanisms not a public library, but just some hidden, internal resource of systemd, that doesn't appear in the search path nor is in any other way publically available.

tpgxyz · 2016-07-26T17:19:43Z

@poettering Thanks for a good explanation what is the purpose libsystemd-shared-231.so library. Everything is now clear. Not an issue.

* Drop support for rcS.d SysV init scripts. These are prone to cause dependency loops, and almost all packages with rcS scripts now ship a native systemd service. * Drop mount propagation patch, it only happens with libseccomp, OE doesnt enable it * kdbus option has disappeared from configure * Ignore dev-so for PN now since systemd introduced private .so see systemd/systemd#3810 Signed-off-by: Khem Raj <raj.khem@gmail.com>

* Drop support for rcS.d SysV init scripts. These are prone to cause dependency loops, and almost all packages with rcS scripts now ship a native systemd service. * Drop mount propagation patch, it only happens with libseccomp, OE doesnt enable it * kdbus option has disappeared from configure * Ignore dev-so for PN now since systemd introduced private .so see systemd/systemd#3810 * Add libnss* to PACKAGES_DYNAMIC for libnss-resolve to work correctly Signed-off-by: Khem Raj <raj.khem@gmail.com>

* Drop support for rcS.d SysV init scripts. These are prone to cause dependency loops, and almost all packages with rcS scripts now ship a native systemd service. * Drop mount propagation patch, it only happens with libseccomp, OE doesnt enable it * kdbus option has disappeared from configure * Ignore dev-so for PN now since systemd introduced private .so see systemd/systemd#3810 * Add libnss* to PACKAGES_DYNAMIC for libnss-resolve to work correctly * Forward port systemd-boot patches to systemd-232 Signed-off-by: Khem Raj <raj.khem@gmail.com>

* Drop support for rcS.d SysV init scripts. These are prone to cause dependency loops, and almost all packages with rcS scripts now ship a native systemd service. * Drop mount propagation patch, it only happens with libseccomp, OE doesnt enable it * kdbus option has disappeared from configure * Ignore dev-so for PN now since systemd introduced private .so see systemd/systemd#3810 * Add libnss* to PACKAGES_DYNAMIC for libnss-resolve to work correctly * Forward port systemd-boot patches to systemd-232 (From OE-core rev: e6c1765a05c1321f08f3d1fb521dfe6b07bc8e92) Signed-off-by: Khem Raj <raj.khem@gmail.com> Signed-off-by: Ross Burton <ross.burton@intel.com>

* Drop support for rcS.d SysV init scripts. These are prone to cause dependency loops, and almost all packages with rcS scripts now ship a native systemd service. * Drop mount propagation patch, it only happens with libseccomp, OE doesnt enable it * kdbus option has disappeared from configure * Ignore dev-so for PN now since systemd introduced private .so see systemd/systemd#3810 * Add libnss* to PACKAGES_DYNAMIC for libnss-resolve to work correctly * Forward port systemd-boot patches to systemd-232 Signed-off-by: Khem Raj <raj.khem@gmail.com> Signed-off-by: Ross Burton <ross.burton@intel.com>

* Drop support for rcS.d SysV init scripts. These are prone to cause dependency loops, and almost all packages with rcS scripts now ship a native systemd service. * Drop mount propagation patch, it only happens with libseccomp, OE doesnt enable it * kdbus option has disappeared from configure * Ignore dev-so for PN now since systemd introduced private .so see systemd/systemd#3810 * Add libnss* to PACKAGES_DYNAMIC for libnss-resolve to work correctly * Forward port systemd-boot patches to systemd-232 (From OE-Core rev: e6c1765a05c1321f08f3d1fb521dfe6b07bc8e92) Signed-off-by: Khem Raj <raj.khem@gmail.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

* Drop support for rcS.d SysV init scripts. These are prone to cause dependency loops, and almost all packages with rcS scripts now ship a native systemd service. * Drop mount propagation patch, it only happens with libseccomp, OE doesnt enable it * kdbus option has disappeared from configure * Ignore dev-so for PN now since systemd introduced private .so see systemd/systemd#3810 * Add libnss* to PACKAGES_DYNAMIC for libnss-resolve to work correctly * Forward port systemd-boot patches to systemd-232 (From OE-core rev: e6c1765a05c1321f08f3d1fb521dfe6b07bc8e92) Signed-off-by: Khem Raj <raj.khem@gmail.com> Signed-off-by: Ross Burton <ross.burton@intel.com>

* Drop support for rcS.d SysV init scripts. These are prone to cause dependency loops, and almost all packages with rcS scripts now ship a native systemd service. * Drop mount propagation patch, it only happens with libseccomp, OE doesnt enable it * kdbus option has disappeared from configure * Ignore dev-so for PN now since systemd introduced private .so see systemd/systemd#3810 * Add libnss* to PACKAGES_DYNAMIC for libnss-resolve to work correctly * Forward port systemd-boot patches to systemd-232 Signed-off-by: Khem Raj <raj.khem@gmail.com>

* Drop support for rcS.d SysV init scripts. These are prone to cause dependency loops, and almost all packages with rcS scripts now ship a native systemd service. * Drop mount propagation patch, it only happens with libseccomp, OE doesnt enable it * kdbus option has disappeared from configure * Ignore dev-so for PN now since systemd introduced private .so see systemd/systemd#3810 * Add libnss* to PACKAGES_DYNAMIC for libnss-resolve to work correctly * Forward port systemd-boot patches to systemd-232 (From OE-core rev: e6c1765a05c1321f08f3d1fb521dfe6b07bc8e92) Signed-off-by: Khem Raj <raj.khem@gmail.com> Signed-off-by: Ross Burton <ross.burton@intel.com>

When building systemd with multilib support enabled in your build you will get the following QA warnings (if the 'libdir' QA check is enabled.) WARNING: systemd-1_232-r0 do_package_qa: QA Issue: systemd-dbg: found \ library in wrong location: /lib/systemd/.debug/libsystemd-shared-232.so systemd: found library in wrong location: /lib/systemd/libsystemd-shared.so systemd: found library in wrong location: /lib/systemd/libsystemd-shared-232.so [libdir] Since systemd 231 upstream has included an 'internal' library which they explicitly place in the application specific /lib/systemd directory. You can see some of the discussion about this placement here systemd/systemd#3810 This placement is being picked up by the QA checker since when multilibs are enabled it expects all libraries to be in lib32 or lib64. Since the systemd and systemd-dbg packages don't contain any other libraries we can respect the upstream placement and skip this QA check for these packages. Unfortunately the QA mechanism doesn't allow us to specify individual files so this approach is the best we can do. (From OE-core rev: 422077ff91c4147f08108fe8510b238730f2367c) Signed-off-by: Mark Asselstine <mark.asselstine@windriver.com> Signed-off-by: Ross Burton <ross.burton@intel.com>