Mailinglist Archive: opensuse-packaging (104 mails)

< Previous Next >
Re: [opensuse-packaging] Splitting up binary packages for large SDKs

On Tuesday 2018-08-07 18:09, Michael Matz wrote:

You could move the static libs (if you chose to enable them, but why would
you when upstream is at least somewhat sensible and provides shared libs)
outside /usr/lib64 into a private directory. Then the library policy is
of no concern to you anymore (for the static libs). Some small
adjustments to the SDK should make the SDK build tools (when users are
using the SDK) use the new directory as the library search path.

How many libs are we talking about?

168 :-).

Sigh. Proper modularization doesn't seem en vouge anymore. :-/

How is upstream even thinking about updating these unversioned shared
libs? Are they thinking?

Isn't the -devel package mandatory when packaging cmake modules,
pkgconfig files and header files? At least rpmlint is complaining about
the files not yet in the -devel package.

If there is a -devel package those files need to be placed in there. If
there's no -devel package to start with those files can go into the main
package. (And I sure hope that this is what rpmlint is checking).

Well, then I would need an override for rpmlint.

So you're saying that rpmlint complains about e.g. cmake files in the main
package even though you didn't even have a -devel subpackage? Seems a
regression in rpmlint :-/ Well, so be it, a -devel package it is then :)

I just pushed an updated version of the package into my home project:

https://build.opensuse.org/package/show/home:glaubitz:branches:Cloud:Tools/aws-sdk-cpp


So all .so files into a -libs package. Pragmatic, but you will have
problems getting this into Factory. If you'd consider putting all the
shared libs into one (versioned) subdirectory of /usr/lib64 (and make
similar adjustments to the SDKs build wrappers for library search paths;
for shared libs you also need the RPATH) you'd avoid all problems the
shared library policy poses to you _and_ would solve the update-libraries
problem as well, at least somewhat.

RPM dependency autotracking uses only the file's basename and the file's
content. If you solely rely on a directory to have a version number, you will
almost certainly have the same ABI problems as without the extra directory.

The only time versions in directory names are useful is when you dlopen
libraries so placed.
But DT_SONAME (the things you see with `ldd`; the things rpm sees)
work without directories.
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-packaging+owner@xxxxxxxxxxxx

< Previous Next >
Follow Ups