On 08/07/2018 05:39 PM, Michael Matz wrote:
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.
Yes, I know what the ramifications are when building static libraries.
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).
Well, the point of the static libraries is usually not to use them for building distribution packages with statically linked binaries but to allow customers to build their own binaries as static. I also disagree that static binaries is a historic thing. In fact, static linking is very popular these days for container applications, for example, and the SDK is specifically targeting cloud applications. Languages like Go even default to static linking by default.
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.
Haven't checked for versioned symbols yet. I will examine the .so files with objdump later to find out.
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?
168 :-).
- 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).
Well, then I would need an override for rpmlint. I just pushed an updated version of the package into my home project:
https://build.opensuse.org/package/show/home:glaubitz:branches:Cloud:Tools/a...
Adrian -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org