[Debian-med-packaging] Question about htslib usage in blat / libucsc source

[John Marshall]

On 27 Jan 2020, at 08:45, Andreas Tille wrote:
> On Fri, Jan 24, 2020 at 02:34:54PM +0000, John Marshall wrote:
>> The kent tree's bundled htslib-1.3 contains a number of local patches to vanilla htslib-1.3:
>>
>> * Add new cram_get_Md5/cram_get_ref_url/cram_get_cache_dir/cram_set_cache_url functions which change HTSlib to use the kent tree's reference path and cache mechanisms instead of HTS_REF and HTS_CACHE
>>
>> * Switch out knetfile to use the kent tree's networking facilities
[snip]
>
> Thanks a lot for your patch.  I've now applied it to the Debian
> packaging Git[1] and removed the code copy from the upstream tarball to
> make sure we have a clean build environment.  Unfortunately I'm running
> into another build issue:
>
> ...
> cc -O -g -g -O2 -fdebug-prefix-map=/build/libucsc-0.0+git20200125.51bc9725+dfsg=. -fstack-protector-strong -Wformat -Werror=format-security -Wall -Wformat -Wimplicit -Wreturn-type -Wuninitialized -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_GNU_SOURCE -DMACHTYPE_x86_64   -Wall -Wformat -Wimplicit -Wreturn-type -Wuninitialized -I../inc -I../../inc -I../../../inc -I../../../../inc -I../../../../../inc -I../htslib -I/include -I/usr/include/libpng16  -o knetUdc.o -c knetUdc.c
> knetUdc.c: In function ‘kuOpen’:
> knetUdc.c:25:3: error: ‘knetFile’ {aka ‘struct knetFile_s’} has no member named ‘udcf’

knetUdc.c just sets up the switching of htslib's knetfile to use the kent native facilities. As you're ignoring that, you can just stub out all of knetUdc.c as in the attached patch.

If they were going to do this properly, they would use hfile_add_scheme_handler() to register higher-priority scheme handlers implemented via their own Udc rather than patching htslib source. I believe those facilities were already available in 1.3, though there is some work to do on the HTSlib side to enable this via a debundled HTSlib [1]. So you should continue to just ignore it rather than implement that at present.

>>>> I admit htslib is famous for breaking its interface.
>>
>> Once again: This statement is both rude and false.
>
> I'm very sorry specifically about beeing rude.  I remember I was not in
> a good mood when writing this - but it was rather caused by the lack of
> blat / ucsc authors to discuss their license.

Fair enough, and no worries. It wasn't particularly fair of me to pick up on something written a long time ago in any case -- apologies for that.

(Though I'm more concerned about the "false" than the "rude". The truth is the HTSlib maintainers do not carelessly break the library's interface. Where you think interfaces have been broken, it is important to communicate specific instances upstream. Especially now that the symbol visibility stuff is in vanilla HTSlib, so you wouldn't be raising false alarms about non-public functions that HTSlib considers internal.)

    John


[1] https://github.com/samtools/htslib/pull/647#issuecomment-359380371



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/debian-med-packaging/attachments/20200130/81b6695f/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: disable-knetUdc.diff
Type: application/octet-stream
Size: 693 bytes
Desc: disable-knetUdc.diff
URL: <http://alioth-lists.debian.net/pipermail/debian-med-packaging/attachments/20200130/81b6695f/attachment.obj>