Mailinglist Archive: opensuse-packaging (104 mails)

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

On Tue, 7 Aug 2018, John Paul Adrian Glaubitz wrote:

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.

They use static linking by default because the designers of Go couldn't be
bothered to think about software modularization on the binary level and
implement it in their initial go compiler but instead decided to ignore
advancements from the last 25 years on that topic. The same as the
container people, but for different reasons.

In these times static libs are the get-results-fast-without-thinking-hard
equivalent to throw-away perl scripts that become unmaintainable after
five years.

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:

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.

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

< Previous Next >