Hi, 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:
https://build.opensuse.org/package/show/home:glaubitz:branches:Cloud:Tools/a...
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. Ciao, Michael. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org