Mailinglist Archive: opensuse-packaging (104 mails)

< Previous Next >
Re: [opensuse-packaging] Splitting up binary packages for large SDKs
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/aws-sdk-cpp

Adrian
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-packaging+owner@xxxxxxxxxxxx

< Previous Next >