Overview
Request 1113693 revoked
- Created by StefanBruens
- In state revoked
-
Open review for
adrianSuSE
Request History
StefanBruens created request
factory-auto added opensuse-review-team as a reviewer
Please review sources
factory-auto accepted review
Check script succeeded
licensedigger accepted review
ok
staging-bot added as a reviewer
Being evaluated by staging project "openSUSE:Factory:Staging:adi:47"
staging-bot accepted review
Picked "openSUSE:Factory:Staging:adi:47"
anag+factory added factory-staging as a reviewer
Being evaluated by group "factory-staging"
anag+factory accepted review
Unstaged from project "openSUSE:Factory:Staging:adi:47"
anag+factory added as a reviewer
Being evaluated by staging project "openSUSE:Factory:Staging:adi:33"
anag+factory accepted review
Picked "openSUSE:Factory:Staging:adi:33"
anag+factory added factory-staging as a reviewer
Being evaluated by group "factory-staging"
anag+factory accepted review
Unstaged from project "openSUSE:Factory:Staging:adi:33"
anag+factory added as a reviewer
Being evaluated by staging project "openSUSE:Factory:Staging:adi:51"
anag+factory accepted review
Picked "openSUSE:Factory:Staging:adi:51"
anag+factory added factory-staging as a reviewer
Being evaluated by group "factory-staging"
anag+factory accepted review
Unstaged from project "openSUSE:Factory:Staging:adi:51"
anag+factory added as a reviewer
Being evaluated by staging project "openSUSE:Factory:Staging:adi:33"
anag+factory accepted review
Picked "openSUSE:Factory:Staging:adi:33"
darix accepted review
Accepted review for by_group opensuse-review-team request 1113693 from user anag+factory
adrianSuSE added adrianSuSE as a reviewer
There is a long standing issue debate upstream regarding the soversion. However, using .so.3 pointing to .so.1.x.y is definitive wrong. Also the lib is not binary compatible as it lacks symbols (protobuf MessagePtr definition). So one of the cura's won't start up in any case. Upstream report from 2017 https://github.com/Ultimaker/libArcus/issues/52
dimstar declined review
> readelf -a libArcus.so.1.1.0 | grep SONAME
0x000000000000000e (SONAME) Library soname: [libArcus.so.3]
This makes no sense - libArcus.so.1.1.0 identifies itself as libArcus.so.3
The package libArcus3 is supposed to deliver files in the form libArcus\.so\.3(\.*)?; libArcus.so.1* is not supposed to be found in a libArcus3 package (as this would forcible conflict with the file identifying itself as libArcus.so.1 plus its subversions)
dimstar declined request
> readelf -a libArcus.so.1.1.0 | grep SONAME
0x000000000000000e (SONAME) Library soname: [libArcus.so.3]
This makes no sense - libArcus.so.1.1.0 identifies itself as libArcus.so.3
The package libArcus3 is supposed to deliver files in the form libArcus\.so\.3(\.*)?; libArcus.so.1* is not supposed to be found in a libArcus3 package (as this would forcible conflict with the file identifying itself as libArcus.so.1 plus its subversions)
StefanBruens reopened request
> readelf -a libArcus.so.1.1.0 | grep SONAME
> 0x000000000000000e (SONAME) Library soname: [libArcus.so.3]
So what? try `readelf -a libArcus.so.3`, that gets what you expect here.
There must be either a file or a symlink matching the SONAME. It is the same as for almost any other library package, there is *no* requirement all files/symlinks have to match the pattern ${SONAME}(.\d+)+, even if it is a common pattern.
I have given plenty of examples for other libraries (ksysguard, libvncserver, libvncclient, libopenjp2, libappstream, libaccounts-glib) which do not follow your assumed, incorrect pattern. (There are more, OpenSceneGraph, libZXing, OpenCV, VTK, many KDE libraries. Are you going to "fix" all these?)
dimstar_suse added factory-staging as a reviewer
Being evaluated by group "factory-staging"
dimstar_suse accepted review
Unstaged from project "openSUSE:Factory:Staging:adi:33"
dimstar_suse declined review
sr#1118907 has newer source and is from the same project
dimstar_suse declined request
sr#1118907 has newer source and is from the same project
StefanBruens revoked request
Honestly, I find the behavior of the involved SUSE employees quite rude.
First, the bad change is pushed and rushed through, completely overruling me as the libArcus maintainer.
And now, this is kept open for two weeks, without any reaction?
@dimstar - If you want to discuss this, fine, but do so in a timely manner. And please finally provide pointers to the section of the SLPP supporting your view point.
You might notice that there is no blocker by me on this request.
The bot sees a correct file conflict here - two packages providing the same filename without having a conflict declared in their PKG meta.
Please add at least the conflict here; then we should probably be able to progress at least
side-note: I checked libvncserver1, libappstream4, and libopenjp2-7:
the packages there are guaranteed never to conflict as the additional files are called after the package version.
i.e: * libvncserver1: /usr/lib64/libvncserver.so.0.9.14 => package versio 0.9.14 * libappstream4: /usr/lib64/libappstream.so.0.16.3 => package version 0.16.3 * libopenjp2-7: /usr/lib64/libopenjp2.so.2.5.0 => package version 2.5.0
So, yes, you are right, the rule I gave is too strict, but not entirely wrong (in avoiding file conflicts across packages). As they contain the version, they are basically guaranteed not to conflict with another version of the package
the slpp says:
In general, versioned packages shall not contain anything but the shared library/libraries. No headers, no devel .so symlink, no config files, no documentation, etc. It may contain the license file if so required, and it must be in a versioned directory. (Using "%doc LICENSE" in a specfile's files section usually suffices.) If a versioned shared library package must contain other files than shared libraries for whatever (approved!) reason, their names must be made unambiguous by putting them in a versioned directory or by versioning their names to not conflict with the rationale of this policy. (Example: the libnl3-200 package has a /usr/lib64/libnl3-200 directory.) The (simpler) alternative: have the shlib package require another package (can be unversioned) for such files, if so supported.i.e 2nd bullet point - 'other files…names must be made unambiguos…by versioning their names'