July 2022 - openSUSE Science - openSUSE Mailing Lists

Leave
by Slawomir Siejka 31 Jul '22

31 Jul '22

Empty Message

1 0

Re: Unannounced change of shlib-policy-name-error rpmlint strictness on TW
by Stefan Brüns 14 Jul '22

14 Jul '22

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

1 0

Unannounced change of shlib-policy-name-error rpmlint strictness on TW
by Stefan Brüns 14 Jul '22

14 Jul '22

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

1 0

Re: RFC: Proper automatic library dependencies for MPI/serial flavors
by Egbert Eich 05 Jul '22

05 Jul '22

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)

1 0

RFC: Proper automatic library dependencies for MPI/serial flavors
by Stefan Brüns 05 Jul '22

05 Jul '22

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

1 0