[opensuse-packaging] Issue with SONAME
Dear all, I am not super skilled with compilation/packaging, but I'm trying to update a package to a newer version for the science repo: https://build.opensuse.org/package/show/home:flyos:branches:science/libhts This library is needed for the SAMtools/BCFtools software for bioinformatics. Details aside, OBS is not happy with this new version because the make install is creating a libhts.so.2: ln -sf libhts.so.1.5 /home/abuild/rpmbuild/BUILDROOT/libhts1-1.5-14.1.x86_64/usr/lib64/libhts.so.2 I don't get why the MAKEFILE is doing this... The problem is that this creates an error at the end because the package is named libhts1 (the version is 1.5...): [ 58s] libhts1.x86_64: E: shlib-policy-name-error (Badness: 10000) libhts2 [ 58s] Your package contains a single shared library but is not named after its [ 58s] SONAME. Any idea on how to correct this? I tried to create a sub-package libhts2 but ended more with even more of a mess... Any help would be very welcome! Cheers, Pierre -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 10/07/17 09:41, Pierre de Villemereuil wrote:
Dear all,
I am not super skilled with compilation/packaging, but I'm trying to update a package to a newer version for the science repo: https://build.opensuse.org/package/show/home:flyos:branches:science/libhts
This library is needed for the SAMtools/BCFtools software for bioinformatics.
Details aside, OBS is not happy with this new version because the make install is creating a libhts.so.2: ln -sf libhts.so.1.5 /home/abuild/rpmbuild/BUILDROOT/libhts1-1.5-14.1.x86_64/usr/lib64/libhts.so.2
I don't get why the MAKEFILE is doing this...
The problem is that this creates an error at the end because the package is named libhts1 (the version is 1.5...): [ 58s] libhts1.x86_64: E: shlib-policy-name-error (Badness: 10000) libhts2 [ 58s] Your package contains a single shared library but is not named after its [ 58s] SONAME.
Any idea on how to correct this? I tried to create a sub-package libhts2 but ended more with even more of a mess... Any help would be very welcome!
Cheers, Pierre
As a bit of background the SONAME is the internal library version, whenever you make incompatible changes to a library you need to increase the version, so it sounds like your upstream has broken compatibility and updated the SONAME correctly but not changed there major version like they probably should have. So even though the version is 1.5 the correct package name is libhts2 but the package version should be 1.5 (Unfortunately upstreams sometimes do silly things and theres not so much we can do about it). -- 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
Hi, Thanks for your help!
As a bit of background the SONAME is the internal library version, whenever you make incompatible changes to a library you need to increase the version, so it sounds like your upstream has broken compatibility and updated the SONAME correctly but not changed there major version like they probably should have. So even though the version is 1.5 the correct package name is libhts2 but the package version should be 1.5 (Unfortunately upstreams sometimes do silly things and theres not so much we can do about it).
This is what I understood and changing the name of the package for libhts2 seems to have fixed the problem indeed. I didn't tried that because I was afraid there was 2 SONAME because of the following lines: [ 46s] install -p -m 644 libhts.so /home/abuild/rpmbuild/BUILDROOT/libhts1-1.5-15.1.x86_64/usr/lib64/libhts.so.1.5 [ 46s] ln -sf libhts.so.1.5 /home/abuild/rpmbuild/BUILDROOT/libhts1-1.5-15.1.x86_64/usr/lib64/libhts.so [ 46s] ln -sf libhts.so.1.5 /home/abuild/rpmbuild/BUILDROOT/libhts1-1.5-15.1.x86_64/usr/lib64/libhts.so.2 I guess I shouldn't extrapolate the SONAME from the filename? (It's a bit blurry for me right now) So, what is openSUSE policy in that kind of case (I'd like to resubmit to the science repo if possible)? Shall I change the specfile name to libhts2 as well? Thanks, Pierre. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 10/07/17 11:45, Pierre de Villemereuil wrote:
Hi,
Thanks for your help!
As a bit of background the SONAME is the internal library version, whenever you make incompatible changes to a library you need to increase the version, so it sounds like your upstream has broken compatibility and updated the SONAME correctly but not changed there major version like they probably should have. So even though the version is 1.5 the correct package name is libhts2 but the package version should be 1.5 (Unfortunately upstreams sometimes do silly things and theres not so much we can do about it).
This is what I understood and changing the name of the package for libhts2 seems to have fixed the problem indeed.
I didn't tried that because I was afraid there was 2 SONAME because of the following lines: [ 46s] install -p -m 644 libhts.so /home/abuild/rpmbuild/BUILDROOT/libhts1-1.5-15.1.x86_64/usr/lib64/libhts.so.1.5 [ 46s] ln -sf libhts.so.1.5 /home/abuild/rpmbuild/BUILDROOT/libhts1-1.5-15.1.x86_64/usr/lib64/libhts.so [ 46s] ln -sf libhts.so.1.5 /home/abuild/rpmbuild/BUILDROOT/libhts1-1.5-15.1.x86_64/usr/lib64/libhts.so.2
I guess I shouldn't extrapolate the SONAME from the filename? (It's a bit blurry for me right now)
So, what is openSUSE policy in that kind of case (I'd like to resubmit to the science repo if possible)? Shall I change the specfile name to libhts2 as well?
Thanks, Pierre.
That looks wrong, can you run objdump -x on the library thats build, from there you will see the SONAME, if its libhts.so.2, the first line should be installing to libhts.so.2, if the SONAME is libhts.so.1.5 the third line creating the symlink to libhts.so.2 shouldn't exist. If your upstream wants to ship both it needs to be compiled twice with the correct SONAME in each version rather then a symlink. -- 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
That looks wrong, can you run objdump -x on the library thats build, from there you will see the SONAME, if its libhts.so.2, the first line should be installing to libhts.so.2, if the SONAME is libhts.so.1.5 the third line creating the symlink to libhts.so.2 shouldn't exist. If your upstream wants to ship both it needs to be compiled twice with the correct SONAME in each version rather then a symlink.
Here's what I get:
objdump -x libhts.so.1.5 | grep "SONAME" SONAME libhts.so.2 objdump -x libhts.so.2 | grep "SONAME" SONAME libhts.so.2
I just looked at the INSTALL file again, and they don't mention anything about this... So, should I hard-copy libhts.so.1.5 to libhts.so.2 and remove libhts.so.1.5? Or leave it be? The problem is that I don't want to break things down the road for the software that depend on this... Cheers, Pierre -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Jul 10 2017, Pierre de Villemereuil
Here's what I get:
objdump -x libhts.so.1.5 | grep "SONAME" SONAME libhts.so.2 objdump -x libhts.so.2 | grep "SONAME" SONAME libhts.so.2
I just looked at the INSTALL file again, and they don't mention anything about this...
So, should I hard-copy libhts.so.1.5 to libhts.so.2 and remove libhts.so.1.5? Or leave it be?
1.5 is just the package version, so nothing wrong with it. Andreas. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Monday 2017-07-10 02:11, Pierre de Villemereuil wrote:
This library is needed for the SAMtools/BCFtools software for bioinformatics.
Details aside, OBS is not happy with this new version because the make install is creating a libhts.so.2: ln -sf libhts.so.1.5 /home/abuild/rpmbuild/BUILDROOT/libhts1-1.5-14.1.x86_64/usr/lib64/libhts.so.2
I don't get why the MAKEFILE is doing this...
The problem is that this creates an error at the end because the package is named libhts1 (the version is 1.5...): [ 58s] libhts1.x86_64: E: shlib-policy-name-error (Badness: 10000) libhts2 [ 58s] Your package contains a single shared library but is not named after its [ 58s] SONAME.
The third problem (unrelated to rpmlint's warnings) is that your specfile is not called libhts.spec as it should, and that the devel subpackage is not called libhts-devel as it should. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
The third problem (unrelated to rpmlint's warnings) is that your specfile is not called libhts.spec as it should, and that the devel subpackage is not called libhts-devel as it should.
I'm not sure I understand. When I first created the package, rpmlint complained (kind of like it does now) that the package should be named libhts1, according to the SONAME and it was actually the only way to make it compile (still is, as far as I can see). The only way I can make sense of your comment is that: - the spec file should be named libhts.spec - the package in the spec file should be named libhts1/libhts2 (depending on the SONAME) - the devel sub-package should not be named libhts1-devel, but renamed libhts-devel Is this what you are suggesting? Thanks for your help, and sorry if I'm being stupid. Cheers, Pierre. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Monday 2017-07-10 11:42, Pierre de Villemereuil wrote:
The third problem (unrelated to rpmlint's warnings) is that your specfile is not called libhts.spec as it should, and that the devel subpackage is not called libhts-devel as it should.
I'm not sure I understand. When I first created the package, rpmlint complained (kind of like it does now) that the package should be named libhts1, according to the SONAME and it was actually the only way to make it compile (still is, as far as I can see).
The only way I can make sense of your comment is that: - the spec file should be named libhts.spec - the package in the spec file should be named libhts1/libhts2 (depending on the SONAME) - the devel sub-package should not be named libhts1-devel, but renamed libhts-devel
Is this what you are suggesting?
libhts.spec Name: libhts %package -n libhts2 %package devel If that was not apparent from https://en.opensuse.org/openSUSE:Shared_library_packaging_policy#Layout_of_t... , I am sorry. Maybe you could suggest a wording you find more suitable? -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Sorry to bother you again guys, but I think I'm close. I just want to make I have it done right. So I changed as Jan suggested, but now, I'm unsure about the baselibs.conf file (somebody helped me do it at the time). Is this correct if I name the library package "libhts2" and the devel one "libhts-devel"? Content of baselibs.conf: libhts2 libhts-devel requires -libhts2-<targettype> requires "libhts2-<targettype> = <version>" Thank you again for your help and sorry to be a pain... Cheers, Pierre. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Monday 2017-07-10 12:29, Pierre de Villemereuil wrote:
Sorry to bother you again guys, but I think I'm close. I just want to make I have it done right.
So I changed as Jan suggested, but now, I'm unsure about the baselibs.conf file (somebody helped me do it at the time). Is this correct if I name the library package "libhts2" and the devel one "libhts-devel"?
Content of baselibs.conf: libhts2 libhts-devel requires -libhts2-<targettype> requires "libhts2-<targettype> = <version>"
First you delete a requires, and then add it back with the exact same name? :-) If you copied that off from some other package, please let us know which, because that would also indicate a bug in that one. Normally, the pattern goes like this and has minimally(!) different names: requires -libhts-... requires libhts2-... -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
First you delete a requires, and then add it back with the exact same name? :-) If you copied that off from some other package, please let us know which, because that would also indicate a bug in that one.
Somebody from the science repo did it for me. I won't give names (because I don't remember who, mostly!). ;)
Normally, the pattern goes like this and has minimally(!) different names:
requires -libhts-... requires libhts2-...
So... libhts2 libhts-devel requires -libhts-<targettype> requires "libhts2-<targettype> = <version>" Am I correct? Thanks so much for your help! A final thing. Since a wild and rogue libhts1-devel package was released in the science repo with the first spec file, should I add a line like: Obsoletes: libhts1-devel in the spec file? To make sure this old package is removed when this one is installed? Cheers, Pierre -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Monday 2017-07-10 12:52, Pierre de Villemereuil wrote:
A final thing. Since a wild and rogue libhts1-devel package was released in the science repo with the first spec file, should I add a line like:
Obsoletes: libhts1-devel
in the spec file? To make sure this old package is removed when this one is installed?
Sounds like a sensible thing. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Hello, Am Montag, 10. Juli 2017, 12:52:36 CEST schrieb Pierre de Villemereuil: ...
A final thing. Since a wild and rogue libhts1-devel package was released in the science repo with the first spec file, should I add a line like:
Obsoletes: libhts1-devel
in the spec file? To make sure this old package is removed when this one is installed?
Yes, but please make it versioned - if someone wants to provide a libhts1-devel package one day, an unversioned Obsoletes will bite you ;-) IIRC you have version 1.5 now, so please use Obsoletes: libhts1-devel <= 1.5 (adjust the number as needed - it should cover all versions of libhts1-devel you ever provided) Regards, Christian Boltz --
unsubscribt. ...oh nein,-noch einer. Jens Du bist es Schuld! Ich würde ja gerne sagen: "Es tut mir leid." Aber ich kann machen was ich will, es kommt mir nicht über die Lippen ;) [>> Matthias Reinhardt, > Harald Huthmann u. Jens Nixdorf in suse-linux]
-- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
participants (5)
-
Andreas Schwab -
Christian Boltz -
Jan Engelhardt -
Pierre de Villemereuil -
Simon Lees