Thank You Dne úterý 18. května 2021 6:28:22 CEST, Dmitriy Perlow napsal(a):

Hello. Please remove Provides: bamtools-devel = %{version}

This indeed helps.

and add read https://en.opensuse.org/openSUSE:Packaging_scriptlet_snippets #Shared_libraries

Here I'm not sure... Using %post /sbin/ldconfig %postun /sbin/ldconfig reduces the warnings. To be sure, it's so, because it's running this on main package and not subpackage (doesn't make sense to run on -devel)? I also still get warning: [ 96s] RPMLINT report: [ 96s] =============== [ 97s] bamtools.x86_64: W: shared-lib-calls-exit /usr/lib64/libbamtools.so.2.5.1 exit@GLIBC_2.2.5 [ 97s] This library package calls exit() or _exit(), probably in a non-fork() [ 97s] context. Doing so from a library is strongly discouraged - when a library [ 97s] function calls exit(), it prevents the calling program from handling the [ 97s] error, reporting it to the user, closing files properly, and cleaning up any [ 97s] state that the program has. It is preferred for the library to return an [ 97s] actual error code and let the calling program decide how to handle the [ 97s] situation. Here I don't know, the spec file doesn't call exit explicitely...

пн, 17 мая 2021, 23:16 карыстальнік Vojtěch Zeisek напісаў:

...

Hi, this is probably very basic problem, but I'm sorry, I'm bit lost... I have spec file like

Name: bamtools Version: 2.5.1 Release: 0 Summary: C++ API & command-line toolkit for working with BAM data License: MIT Group: Productivity/Scientific/Other URL: https://github.com/pezmaster31/bamtools/wiki Source: https://github.com/pezmaster31/bamtools/archive/refs/tags/ v%{version}.tar.gz#/bamtools-%{version}.tar.gz BuildRequires: cmake BuildRequires: gcc BuildRequires: gcc-c++ BuildRequires: pkgconfig BuildRequires: zlib-devel

%description BamTools is a project that provides both a C++ API and a command-line toolkit for reading, writing, and manipulating BAM (genome alignment) files.

%package devel Summary: Developmental files for bamtools Requires: bamtools = %{version} Provides: bamtools-devel = %{version} Obsoletes: bamtools-devel < %{version}

%description devel Developmental files for BamTools, s a project that provides both a C++ API and a command-line toolkit for reading, writing, and manipulating BAM (genome alignment) files.

%prep %setup -q

%build %cmake -DBUILD_SHARED_LIBS=ON

%install %cmake_install DESTDIR=%{buildroot}

%check %ctest

%post -n bamtools-devel -p /sbin/ldconfig %postun -n bamtools-devel -p /sbin/ldconfig

%files devel %{_includedir}/* %{_libdir}/*.so %{_libdir}/pkgconfig/*.pc

%files %license LICENSE %{_bindir}/* %{_libdir}/*so.*

%changelog

and it does produce bamtools RPM looking fine (providing working bamtools binary), but I also get several warnings from 'osc build --local-package'

[ 77s] RPMLINT report: [ 77s] =============== [ 78s] bamtools.x86_64: W: library-without-ldconfig-postin /usr/lib64/libbamtools.so.2.5.1 [ 78s] This package contains a library and provides no %post scriptlet containing a [ 78s] call to ldconfig. [ 78s] [ 78s] bamtools.x86_64: W: library-without-ldconfig-postun /usr/lib64/libbamtools.so.2.5.1 [ 78s] This package contains a library and provides no %postun scriptlet containing a [ 78s] call to ldconfig. [ 78s] [ 78s] bamtools.x86_64: W: shared-lib-calls-exit /usr/lib64/libbamtools.so.2.5.1 exit@GLIBC_2.2.5 [ 78s] This library package calls exit() or _exit(), probably in a non-fork() [ 78s] context. Doing so from a library is strongly discouraged - when a library [ 78s] function calls exit(), it prevents the calling program from handling the [ 78s] error, reporting it to the user, closing files properly, and cleaning up any [ 78s] state that the program has. It is preferred for the library to return an [ 78s] actual error code and let the calling program decide how to handle the [ 78s] situation. [ 78s] [ 78s] bamtools-devel.x86_64: W: useless-provides bamtools-devel [ 78s] This package provides 2 times the same capacity. It should only provide it [ 78s] once. [ 78s] [ 78s] 3 packages and 0 specfiles checked; 0 errors, 4 warnings.

Could anyone, please, point me to the way to fix the above warnings to make rpmlint happy? I'm probably missing how to split the source package into appropriate binary packages. I hope the spec source shows I tried to find the way myself, but failed. :-) -- Vojtěch Zeisek https://trapa.cz/

Komunita openSUSE GNU/Linuxu Community of the openSUSE GNU/Linux https://www.opensuse.org/

Dne úterý 18. května 2021 9:37:24 CEST, Christian Goll napsal(a):

On 18.05.21 09:26, Vojtěch Zeisek wrote:

...

Dne úterý 18. května 2021 6:28:22 CEST, Dmitriy Perlow napsal(a):

...

Hello. Please remove Provides: bamtools-devel = %{version}

This indeed helps.

...

and add read https://en.opensuse.org/openSUSE:Packaging_scriptlet_snippets #Shared_libraries

Here I'm not sure... Using

%post /sbin/ldconfig %postun /sbin/ldconfig

Or as 'spec-cleaner -d bamtools.spec' says: %post -p /sbin/ldconfig %postun -p /sbin/ldconfig

...

reduces the warnings. To be sure, it's so, because it's running this on main package and not subpackage (doesn't make sense to run on -devel)? I also still get warning:

[ 96s] RPMLINT report: [ 96s] =============== [ 97s] bamtools.x86_64: W: shared-lib-calls-exit /usr/lib64/libbamtools.so.2.5.1 exit@GLIBC_2.2.5 [ 97s] This library package calls exit() or _exit(), probably in a non-fork() [ 97s] context. Doing so from a library is strongly discouraged - when a library [ 97s] function calls exit(), it prevents the calling program from handling the [ 97s] error, reporting it to the user, closing files properly, and cleaning up any [ 97s] state that the program has. It is preferred for the library to return an [ 97s] actual error code and let the calling program decide how to handle the [ 97s] situation.

Here I don't know, the spec file doesn't call exit explicitely...

The warning means, that the library exists the program at an error instead of returning an error code to the calling binary. This is considered as bad practice, but has to be fixed upstream. So you can ignore it.

OK, thank You, submitted to OBS, I'm going to report it upstream. :-) -- Vojtěch Zeisek https://trapa.cz/ Komunita openSUSE GNU/Linuxu Community of the openSUSE GNU/Linux https://www.opensuse.org/

On Tuesday 2021-05-18 10:45, Simon Lees wrote:

...

...

The warning means, that the library exists the program at an error instead of returning an error code to the calling binary. This is considered as bad practice, but has to be fixed upstream. So you can ignore it.

OK, thank You, submitted to OBS, I'm going to report it upstream. :-)

Its also worth noting that in some cases upstream has a really good reason for this (or the error is incorrect) and in such cases you can continue to ignore the warning (this is why its a warning not an error).

Unless a library uses fork() to make some new processes, I can't really see an excuse for "exit". At minimum, that should be an abort. Or, since it's a C++ code section, "throw" (which counts towards the proper implementation of "error code").

On Tuesday 2021-05-18 12:20, Johannes Meixner wrote:

If the rpmlint test inspects the compiled library and finds that it calls exit or abort then both behave malicious in the same way for end-users because for the user the program just gets "killed" without any chance to get a meaningful (error) message.

According to "man 3 abort" it seems abort is even more "brutal" than exit because "starting with glibc 2.27, abort() terminates the process without flushing streams".

Unlike exit however, abort raises SIGABRT, which in normal circumstances should generate a coredump and hence a stacktrace is available that shows how execution even got there in the first place.

exit or abort then both behave malicious in the same way for end-users because for the user the program just gets "killed"

In a way, that is a good thing. If the library quality is such that it needs to exit/abort (for non-fork cases) in the first place, you have to expect switching those exit functions out for a return code could cause (possibly silent) data corruption later on, because the remaining program is missing the flows necessary to support what was previously a [[noreturn]] scenario.

Simply put: In normal environments library calls must not terminate the caller.

Ideally yeah, but ideals got thrown out the window with this version of the library ;-)