This request is superseded by
request 782558
(Show diff)
Overview
Request 782555 superseded
dependency of capi4hylafax, previously provided by i4l-base
- Created by seife
- In state superseded
- Superseded by 782558
- Open review for factory-staging
- Open review for opensuse-review-team
Loading...
Request History
seife created request
dependency of capi4hylafax, previously provided by i4l-base
factory-auto added opensuse-review-team as a reviewer
Please review sources
factory-auto accepted review
Check script succeeded
licensedigger accepted review
ok
libcapi20-3.i586: E: devel-file-in-non-devel-package (Badness: 50) /usr/lib/capi/lib_capi_mod_fritzbox.so libcapi20-3.i586: E: devel-file-in-non-devel-package (Badness: 50) /usr/lib/capi/lib_capi_mod_rcapi.so libcapi20-3.i586: E: devel-file-in-non-devel-package (Badness: 50) /usr/lib/capi/lib_capi_mod_std.so A file that is needed only e.g. when developing or building software is included in a non-devel package. These files should go in devel packages.
Does not comply to slpp...
The debian package has the same file list. The .so not in -devel.
I suspect this might be how this stuff works, by dynamically loading via dlopen the "lib_capi_mod_$PROVIDER.so"
As I have no way to verify this, I decided to do as debian does.
i4l-base has the same problem btw, just to a much bigger extent.
So libcapi20 is at least an improvement over i4l-base ;-)
looking at the code, it actually tries dlopen()ing all '*.so.2', so the *.so can go to -devel (probably could be just removed, but who knows...) Sending an updated SR soon.
Sorry, I did not even mean the so stuff itself. Just realized that I copied to much into the message.
The problem here are files not following the library versioning. If (as unlikely as it may be) the so ane bumps, we get file conflicts on upgrades
Also: can we drop the static libs?
Yes.
Many thanks to to seife for looking at this it was on my TODOs for very long term. Yes these libraries are not libraries for dynamic linking, they are plugins and so the main CAPI library load them via dlopen depending which hardware was configured. For doing this it simple opens the .so file -so the .so files are mandatory and not -devel files. Here should be no issue in the update case, since it makes no sense to have two versions installed at the same time. Maybe we can rename them, if the name is really a problem.
Sorry, I did not want to spam everybody by e-mail, this was an accident.