Mailinglist Archive: opensuse-packaging (104 mails)

< Previous Next >
Re: [opensuse-packaging] Splitting up binary packages for large SDKs
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@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-packaging+owner@xxxxxxxxxxxx

< Previous Next >