Hello. Please remove Provides: bamtools-devel = %{version} and add read https://en.opensuse.org/openSUSE:Packaging_scriptlet_snippets#Shared_librari... пн, 17 мая 2021, 23:16 карыстальнік Vojtěch Zeisek < vojtech.zeisek@opensuse.org> напісаў:

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/

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

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

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. kind regards, Christian

On 5/18/21 5:11 PM, Vojtěch Zeisek wrote:

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

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). -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B

Hello, On 2021-05-18 11:51, Jan Engelhardt wrote:

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

...

...

...

The warning means, that the library exists the program

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

I think things depend on how that rpmlint test is implemented. The rpmlint message was (long line wrapped) --------------------------------------------------------------------- RPMLINT report: bamtools.x86_64: W: shared-lib-calls-exit /usr/lib64/libbamtools.so.2.5.1 exit@GLIBC_2.2.5 --------------------------------------------------------------------- so it looks as if the rpmlint test inspects the compiled library /usr/lib64/libbamtools.so.2.5.1 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". In contrast if the rpmlint test inspects the source code and finds that the library calls exit or abort then it could be false alarm when those calls get compiled only when some special use case is configured (e.g. via "configure --with-assertions" or similar) that is only meant to be used e.g. by software developers but not in normal end-user environments. Simply put: In normal environments library calls must not terminate the caller. Kind Regards Johannes Meixner -- SUSE Software Solutions Germany GmbH Maxfeldstr. 5 - 90409 Nuernberg - Germany (HRB 36809, AG Nuernberg) GF: Felix Imendoerffer

Hello, On 2021-05-18 13:11, Jan Engelhardt wrote:

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.

That is why I wrote about when those calls get compiled only when some special use case is configured (e.g. via "configure --with-assertions" or similar) that is only meant to be used e.g. by software developers but not in normal end-user environments. I.e. abort during runtime is useful for developers so that they can analyze the coredump how things failed but for normal end-users that user experience is really bad. Kind Regards Johannes Meixner -- SUSE Software Solutions Germany GmbH Maxfeldstr. 5 - 90409 Nuernberg - Germany (HRB 36809, AG Nuernberg) GF: Felix Imendoerffer