Hi, On Tue, 7 Aug 2018, John Paul Adrian Glaubitz wrote:
If the SDK supports the option of disabling static libraries do that. If not, package the static libs separately (into xxx-devel-static for instance), if the SDK then at least has the option of not using static libs.
I currently use the default cmake setting in the SDK which is BUILD_SHARED_LIBS=ON, so I'm not getting any static libraries.
Is there a way to have the %cmake macro build both variants? Although I don't think we need both of them.
No static libs please, then. They aren't allowed by default because they create more problems than they solve: if you have a bug in them (say a security problem) you need to not only deliver an updated library to customers, but actually re-link all applications making use of them and deliver all _those_ to customers. There are cases where we deliver static libs, they are usually historic cases, or where upstream doesn't provide shared libs (and they can't be made easily). But no new static libs without Very Good Reasons (tm).
So, for something like that SDK (without knowing its details) I'd expect these binary rpms:
- libfoo1 - libfoo2 - libfoo3 (and so on for all individual shared libs in {,/usr}/lib{,64})
That would result in a large number of libfoo packages due to the large number of .so files. Also, since the .so files are unversioned, I'm not sure whether the naming scheme applies here.
Urgs, they are unversioned? Sigh. Are they using symbol versioning? If not they shouldn't be in /usr/lib64 then. Unversioned shared libraries without symbol versioning can't ever be nively updated. But yes, one package per shared lib by default. There are exceptions to that, and this might be one (e.g. because they all belong intricately together and could just as well be merged into one large AWS shared library). But as soon as they can be used sensibly separately (e.g. if the programs envisioned to be created with the SDK sometimes use this and sometimes another features, and therefore link against different subsets of the provided shared libs) they have to go into separate packages. How many libs are we talking about?
- awk-sdk-cpp-devel-static (if really needed and indeed optional) - aws-sdk-cpp-devel (if not folded into aws-sdk-cpp)
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). Ciao, Michael. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org