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_...
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@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org