On Donnerstag, 14. Juli 2022 14:34:27 CEST Richard Biener wrote:
> On Thu, 14 Jul 2022, Stefan Brüns wrote:
> > Hi,
> >
> > a few days ago any violation of shlib-policy-name-error has become a fatal
> > error.
> >
> > This is especially problematic for many packages in the science
> > repository,
> > when packages are built as flavors for e.g. openmpi2/3/4, and the library
> > packages carry a corresponding suffix. E.g.:
> >
> > libhdf5-103-openmpi4.x86_64: E: shlib-policy-name-error (Badness: 10000)
> > SONAME: libhdf5.so.103
> > (/usr/lib64/mpi/gcc/openmpi4/lib64/libhdf5.so.103.3.1), expected package
> > suffix: 103
> >
> > This is a case not covered by https://en.opensuse.org/
> > openSUSE:Shared_library_packaging_policy
> >
> > Can this please be reverted until the policy has been extended to cover
> > these cases? Preferably, rpmlint learns to understand this pattern.
>
> The policy wasn't originally supposed to apply to shared libraries
> that do not reside in the default runpath which means
> /usr/lib*/$package/... should have been excempted. Possibly the
> implementation doesn't reflect that or the implementation
> is too narrow?
>
> IIRC there's also a whitelist(?) - the GCC package excempts itself
> via rpmlintrc filtering the check ...
>
> Richard.
In the current code I can not find such a generic exemption.
Of course one can add an exemption via rpmlintrc. I would prefer not do so:
1. There are probably about 50 source packages in science alone affected by
this.
2. Each rpmlintrc entry bears the risk of hiding actual packaging errors.
Regards,
Stefan
--
Stefan Brüns / Bergstraße 21 / 52062 Aachen
phone: +49 241 53809034 mobile: +49 151 50412019
Hi,
a few days ago any violation of shlib-policy-name-error has become a fatal
error.
This is especially problematic for many packages in the science repository,
when packages are built as flavors for e.g. openmpi2/3/4, and the library
packages carry a corresponding suffix. E.g.:
libhdf5-103-openmpi4.x86_64: E: shlib-policy-name-error (Badness: 10000)
SONAME: libhdf5.so.103 (/usr/lib64/mpi/gcc/openmpi4/lib64/libhdf5.so.103.3.1),
expected package suffix: 103
This is a case not covered by https://en.opensuse.org/
openSUSE:Shared_library_packaging_policy
Can this please be reverted until the policy has been extended to cover these
cases? Preferably, rpmlint learns to understand this pattern.
Regards,
Stefan
--
Stefan Brüns / Bergstraße 21 / 52062 Aachen
home: +49 241 53809034 mobile: +49 151 50412019
Hi Stefan,
Stefan Brüns writes:
> Hi everyone,
>
> we have a reocurring problem with multiple providers of libraries built as
> serial and openMPI(1-4)/MVAPICH/... flavors.
>
> Currently, both the serial and e.g. openMPI4 flavors provide the exact same
> resolvables, e.g. "libsundials_sunlinsolklu.so.4.2.0()(64bit)" [1]. This is
> then manually fixed up on a case-by-case basis by manually specifying the
> default package.
>
> Fedora solves this problem by adding the MPI flavor to the resolvable, e.g.
> "libfoo.so()(64bit)(openmpi-x86_64)". For details, see [2][3].
>
> I would propose for (open)SUSE to follow this notation, and finally get rid
> of the manual workarounds.
Indeed, this problem is not new and I believe we've talked about this
some years ago already.
We had the same with HPC packages as well, we 'solved' it by replacing
the dependency generator by one that would ignore any dependencies pointing
into the HPC directories (/usr/lib/hpc) and adding dependencies manually.
I had the plan to resolve it the way you've suggested adding more
'attribute tags' do the dependency to specify it with greater detail.
This of course wasn't the real solution, just a workaround. I never found
time to do the real solution.
So indeed, if Fedora has a solution for this already (at least for the
MPI problem, for HPC packages there are further challanges), we should
take this into consideration.
Thanks for picking this up again!
Cheers,
Egbert.
>
> Kind regards, Stefan
>
>
> [1] https://build.opensuse.org/package/binary/science/sundials:openmpi4/
> openSUSE_Tumbleweed/x86_64/libsundials4-openmpi4-6.2.0-19.1.x86_64.rpm
>
> [2] https://fedoraproject.org/wiki/Changes/RpmMPIReqProv
> [3] https://packages.fedoraproject.org/pkgs/rpm-mpi-hooks/rpm-mpi-hooks/
> index.html
>
--
Egbert Eich (Res. & Dev.) SUSE Labs - Architect HPC
Tel: +49 911-740 53 0 https://www.suse.com
-----------------------------------------------------------------------
SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg
Geschaeftsfuehrer: Ivo Totev
(HRB 36809, AG Nürnberg)
Hi everyone,
we have a reocurring problem with multiple providers of libraries built as
serial and openMPI(1-4)/MVAPICH/... flavors.
Currently, both the serial and e.g. openMPI4 flavors provide the exact same
resolvables, e.g. "libsundials_sunlinsolklu.so.4.2.0()(64bit)" [1]. This is
then manually fixed up on a case-by-case basis by manually specifying the
default package.
Fedora solves this problem by adding the MPI flavor to the resolvable, e.g.
"libfoo.so()(64bit)(openmpi-x86_64)". For details, see [2][3].
I would propose for (open)SUSE to follow this notation, and finally get rid
of the manual workarounds.
Kind regards, Stefan
[1] https://build.opensuse.org/package/binary/science/sundials:openmpi4/
openSUSE_Tumbleweed/x86_64/libsundials4-openmpi4-6.2.0-19.1.x86_64.rpm
[2] https://fedoraproject.org/wiki/Changes/RpmMPIReqProv
[3] https://packages.fedoraproject.org/pkgs/rpm-mpi-hooks/rpm-mpi-hooks/
index.html
