Review swap (htslib)

[Jun Aruga]

Hi all,

Someone (especially proven packagers), could you review below library
package related to bio science?
It has already been reviewed several times. I think I fixed every
items mentioned by a reviewer.

Review Request: htslib - C library for high-throughput sequencing data
formats (required for `samtools`)
https://bugzilla.redhat.com/show_bug.cgi?id=1326504

Happy to review anything in exchange.

Thanks.

-- 
Jun | He - His - Him

[Jun Aruga]

Someone, could give us advice about below situation, if the new
package htslib's "/usr/lib64/libhts.so.1.9" is valid?
"1.9" is upstream software's version. "2" is ABI's version (so
version).

```
<mock-chroot> sh-5.0# ls -l /usr/lib64/libhts.so*
lrwxrwxrwx 1 root root     13 Oct  2 23:50 /usr/lib64/libhts.so -> libhts.so.1.9
-rwxr-xr-x 1 root root 759680 Oct  2 23:50 /usr/lib64/libhts.so.1.9
lrwxrwxrwx 1 root root     13 Oct  2 23:50 /usr/lib64/libhts.so.2 ->
libhts.so.1.9
```

I thought it was valid, because we see many examples like following libraries.
But there is an objection for that on the ticket.
I think if the htslib pattern is wrong, we need to update the guideline.
https://docs.fedoraproject.org/en-US/packaging-guidelines/

```
$ ls -l /usr/lib64/libz.so*
lrwxrwxrwx 1 root root     14 Aug 15 09:30 /usr/lib64/libz.so -> libz.so.1.2.11*
lrwxrwxrwx 1 root root     14 Aug 15 09:30 /usr/lib64/libz.so.1 ->
libz.so.1.2.11*
-rwxr-xr-x 1 root root 128904 Aug 15 09:30 /usr/lib64/libz.so.1.2.11*
```

```
$ find /usr/lib64 -name "lib*.so.*" -a -type f
/usr/lib64/libKF5SyntaxHighlighting.so.5.59.0
/usr/lib64/libxcb.so.1.1.0
/usr/lib64/liburcu-common.so.6.0.0
...

$ find /usr/lib64 -name "lib*.so.*" -a -type f | wc -l
2082
```

Could you comment here or on below ticket?
Someone, could you be an sponsor of the reporter of the ticket?
https://bugzilla.redhat.com/show_bug.cgi?id=1326504#c42

Thanks.

-- 
Jun | He - His - Him

[Zbigniew Jędrzejewski-Szmek]

On Tue, Oct 08, 2019 at 06:03:26PM +0200, Jun Aruga wrote:
>  Someone, could give us advice about below situation, if the new
>  package htslib's "/usr/lib64/libhts.so.1.9" is valid?
>  "1.9" is upstream software's version. "2" is ABI's version
> (so version). 
The patterns used in filenames of so objects aren't really well defined.
In particular, the numbers typically used like libfoo.so.MAJOR.MINOR.PATCH
are only informative.

The libhts convention is: libhts.so.SO_VERSION → libhts.so.PROJECT_VERSION.
Upstream correctly says that there's no chance of conflict because PROJECT_VERSION
always includes a dot and SO_VERSION doesn't. The compiler doesn't care.

I'd say that this is a bit misleading, but not wrong. Not worth deviating
from upstream.

FTR:
In [34]: d = os.scandir('/usr/lib64') 
    ...: for e in d: 
    ...:     if e.is_symlink() and '.so.' in e.name and not
e.name.startswith('.'): 
    ...:          t = os.readlink(e.path) 
    ...:          if e.name not in t and '.so.' in t: 
    ...:              print(e.name, t) 
    ...:                                                                                  
                     
libgcalc-1.so.0.0.0 libgcalc-1.so.0
libosgFX.so.131 libosgFX.so.3.4.1
libcrypto.so.10 libcrypto.so.1.0.2o
libzzip-0.so.12 libzzip-0.so.13
libosgManipulator.so.131 libosgManipulator.so.3.4.1
libosgUtil.so.131 libosgUtil.so.3.4.1
libXaw.so.7 libXaw7.so.7
libexiv2.so.27 libexiv2.so.0.27.2
libOpenThreads.so.20 libOpenThreads.so.3.3.0
libosgWidget.so.131 libosgWidget.so.3.4.1
libosgParticle.so.131 libosgParticle.so.3.4.1
libgcr-3.so.1 libgcr-ui-3.so.1.0.0
libosgText.so.131 libosgText.so.3.4.1
libzzipfseeko-0.so.12 libzzipfseeko-0.so.13
libclucene-contribs-lib.so.1 libclucene-contribs-lib.so.2.3.3.4
libjsoncpp.so.21 libjsoncpp.so.1.9.1
libgit2.so.28 libgit2.so.0.28.3
libkbookmarkmodel_private.so.6 libkbookmarkmodel_private.so.5.97.0
libosgVolume.so.131 libosgVolume.so.3.4.1
libssl.so.10 libssl.so.1.0.2o
libosgViewer.so.131 libosgViewer.so.3.4.1
libmono-2.0.so.1.0.0 libmonosgen-2.0.so.1.0.0
libosgDB.so.131 libosgDB.so.3.4.1
libzzipmmapped-0.so.10 libzzipmmapped-0.so.13
libssh_threads.so.4.8.1 libssh.so.4.8.1
libzzip-0.so.11 libzzip-0.so.13
libzzipmmapped-0.so.11 libzzipmmapped-0.so.13
libosgSim.so.131 libosgSim.so.3.4.1
libosgTerrain.so.131 libosgTerrain.so.3.4.1
libv8_libbase.so.7 /usr/lib64/libnode.so.72
libKF5KExiv2.so.15.0.0 libKF5KExiv2.so.5.0.0
libzzip-0.so.10 libzzip-0.so.13
libminizip.so.2.5 libminizip.so.2.8.9
libosgAnimation.so.131 libosgAnimation.so.3.4.1
libGLX_system.so.0 /usr/lib64/libGLX_mesa.so.0
libutempter.so.0 libutempter.so.1.1.6
libzzipfseeko-0.so.10 libzzipfseeko-0.so.13
libv8.so.7 /usr/lib64/libnode.so.72
libclucene-shared.so.1 libclucene-shared.so.2.3.3.4
libv8_libplatform.so.7 /usr/lib64/libnode.so.72
libzzipfseeko-0.so.11 libzzipfseeko-0.so.13
libgcc_s.so.1 libgcc_s-9-20190827.so.1
libclucene-core.so.1 libclucene-core.so.2.3.3.4
libosgShadow.so.131 libosgShadow.so.3.4.1
libopencc.so.2 libopencc.so.1.0.0
libssh_threads.so.4 libssh.so.4.8.1
libosgUI.so.131 libosgUI.so.3.4.1
libclutter-glx-1.0.so.0 libclutter-1.0.so.0.2600.2
libosgPresentation.so.131 libosgPresentation.so.3.4.1
libosgGA.so.131 libosgGA.so.3.4.1
libosg.so.131 libosg.so.3.4.1
libfbclient.so.2 libfbclient.so.3.0.4
libmono-2.0.so.1 libmonosgen-2.0.so.1
libgit2.so.27 libgit2.so.0.27.8
libzzipmmapped-0.so.12 libzzipmmapped-0.so.13
libgcr-3.so.1.0.0 libgcr-ui-3.so.1.0.0
libopenjp2.so.7 libopenjp2.so.2.3.1

... so yeah, this happens quite a bit.

Zbyszek

[Kevin Kofler]

Jun Aruga wrote:
>  Someone, could give us advice about below situation, if the new
>  package htslib's "/usr/lib64/libhts.so.1.9" is valid?
>  "1.9" is upstream software's version. "2" is ABI's version
> (so version). 
This can happen with non-autotools, non-libtool projects. libtool enforces 
some strict rules where the full version must be of the form 
major.minor.revision and the major version just major. (Actually, libtool 
doesn't even let you specify major and minor directly, but LT_CURRENT and 
LT_AGE, and it computes major=LT_CURRENT-LT_AGE and minor=LT_AGE for you.) 
Other build systems such as CMake allow you to set arbitrary strings as the 
major version and the full version, and the major version need not 
necessarily be a prefix of the full version. So they will let you get away 
with 1.9 as the full version and 2 as the major version.

There is nothing wrong with arbitrary versions if the build system used by 
upstream allows them. The Fedora packages should NOT change the upstream 
versioning scheme because it would make the packages incompatible with 
upstream.

So, to sum it up, yes, /usr/lib64/libhts.so.1.9 and /usr/lib64/libhts.so.2 
is a valid combination. Unusual, but valid.

        Kevin Kofler

[Jun Aruga]

Hi Zbigniew and Kevin

Many thanks for your explanation.
I clearly understand the htslib's situation now.

-- 
Jun | He - His - Him