Mailinglist Archive: opensuse-packaging (104 mails)

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

On 08/07/2018 04:56 PM, Michael Matz wrote:
In Debian, we usually put all shared library files into a lib$NAME$SOVER
package where $NAME is the library name and $SOVER it's SO version.
Development files such as headers, cmake files and static library
archives go into a lib$NAME-dev package. What's the policy for openSUSE?

Specifically for shared libraries:
https://en.opensuse.org/openSUSE:Shared_library_packaging_policy
which also talks about -devel packages. Of relevance:
* There is no reason why a -devel package cannot provide development
files for multiple shared library packages.

Since the SDK has a large number of submodules, I wasn't planning on creating
individual -devel packages anyway. The number of binary packages would have
just been too large.

Also the -devel package doesn't have to (but can) be named lib$NAME-devel.
It might make sense to call it aws-devel, or even package the devel files
(headers, .so links and such) into the main package (if that exists).

Yes, I just found that information as well. An additional important point
that probably applies here is unversioned .so files:

https://en.opensuse.org/openSUSE:Specfile_guidelines#Development_files

Unversioned shared libraries (e.g. libfoo.so). Versioned shared libraries,
e.g. libfoo.so.3, libfoo.so.3.0.0 should not be in -devel.

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.

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.

- 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.

- aws-sdk-cpp (the rest)

See exceptions 4a/4b in the above policy for when also the -devel packages
need to be versioned (I'd hope it's not supported to install multiple
AWK-SDK version onto the same system).

Multiple versions don't seem supported. But installing the SDK for multiple
platforms.

Also, while the package built fine on my AMD EPYC machine (except for
the failing installation process due to the missing %files statements),
on OBS the package occasionally fails with out-of-memory errors or even
the compiler segfaulting.

Compiler segfaulting is no resource problem, but either a compiler bug, or
a flaky machine (usually when the compiler segfault can't be reproduced).

Yes, I'm aware of that. I shouldn't have put the segfault into the same
sentence.

Is there any chance to schedule large packages onto beefier build
instances?

You want build constraints:
https://openbuildservice.org/help/manuals/obs-reference-guide/cha.obs.build_job_constraints.html

See e.g.
% osc cat devel:gcc/gcc8/_constraints

Careful with specifying too strong constraints, not all architectures
provide build hosts with much RAM, if you're using too large numbers your
package won't ever be scheduled for building. For curren resource usage
of build e.g.:
% osc api /build/openSUSE:Factory/standard/x86_64/gcc8/_statistics

Ah, that's handy. Thanks for the hint.

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

< Previous Next >