Bug#971542: Please enable HTSlib plugins
On 7 Oct 2020, at 14:16, Andreas Tille wrote: > > On Wed, Oct 07, 2020 at 09:36:06AM +, John Marshall wrote: >> --enable-plugins --with-plugin-dir='$(libdir)/htslib' >> --with-plugin-path='/usr/local/lib/htslib:/usr/local/libexec/htslib:$(plugindir)' > > OK, that's in Git now Great, thanks. >> BTW it looks like htslib-s3-plugin.7.gz has ben placed in libhts3 basically >> by default, although that is the right package for it. > > Sorry, I do not understand this sentence. There are lines in libhts-dev.install (now libhts3.install -- thanks) for man5, so I expected to see a line for man7 in some *.install file. But now I see there are also *.manpages files which take care of this file. So never mind then, my mistake. >> How can I verify / test the correct setting? > > What exactly do you mean? Test my lastest changes I mentioned above or > rather testing the package that is in unstable currently? Sorry, this was a reply to your previous question but my mail client garbled the exchange with its unintended rich text. You previously asked Andreas> How can I verify / test the correct setting? which I took to mean how do you verify that your plugin-dir and plugin-path configure settings are effective, i.e., how does one verify what plugin directories HTSlib is actually searching. And the answer is By observing the -DPLUGINPATH=… setting that goes past in the log when plugin.c is compiled; by running `strings` on libhts.so; or by seeing what directories are scanned via e.g. `strace htsfile foo:bar 2>&1|grep O_DIRECTORY`. (So no changes are needed. This is how you could check what plugin path settings are burnt into the library if you wanted to.) John
Bug#971542: Please enable HTSlib plugins
On Wed, Oct 07, 2020 at 09:36:06AM +, John Marshall wrote: > > There is no need to patch configure.ac to alter this. Just add > --with-plugin-dir='$(libdir)/htslib' as another configure option. > > I see Debian policy at last now blesses FHS 3.0, which includes libexec. > However you may not wish to be in the vanguard of this, so that > /usr/lib/ARCH/htslib would indeed appear to be the existing-Debian-style > appropriate place under /usr. For /usr/local, any third-party instructions > are likely to recommend installing their plugin into > /usr/local/libexec/htslib, so I would recommend configuring with > > --enable-plugins --with-plugin-dir='$(libdir)/htslib' > --with-plugin-path='/usr/local/lib/htslib:/usr/local/libexec/htslib:$(plugindir)' OK, that's in Git now > as being the most flexible for your users. (These directories are just > scanned for files matching hfile_*.so; it is not an error if any of them does > not exist.) > > BTW it looks like htslib-s3-plugin.7.gz has ben placed in libhts3 basically > by default, although that is the right package for it. Sorry, I do not understand this sentence. > IMHO that would also be the right package for man5/*.5.gz as these are man > pages aimed at users (not just developers) but YMMV. Done in Git. > How can I verify / test the correct setting? What exactly do you mean? Test my lastest changes I mentioned above or rather testing the package that is in unstable currently? > By observing the -DPLUGINPATH=… setting that goes past in the log when > plugin.c is compiled; by running `strings` on libhts.so; or by seeing what > directories are scanned via e.g. `strace htsfile foo:bar 2>&1|grep > O_DIRECTORY`. Sorry, I do not understand what you want to express / want me to change. Thanks a lot for your helpful hints Andreas. -- http://fam-tille.de
Bug#971542: Please enable HTSlib plugins
On 2 Oct 2020, at 10:45, Andreas Tille mailto:andr...@fam-tille.de>> wrote: Please inspect https://salsa.debian.org/med-team/htslib/-/commit/88644ba8e4096302d996dae2a0399195e2e53819 That is the right place for configure options. (and also your hint to the pull request https://salsa.debian.org/med-team/htslib/-/commit/84fcfcfda2b0b89d743bc8adb617abdf5cc22d4b ) That looks correct. See HTSlib's INSTALL file for details. Packagers such as yourselves should set with-plugin-path thus so that plugins in both /usr/local and /usr will be used; If Debian still folds /usr/libexec into /usr/lib or nearby, you may wish to adjust both --with-plugin-dir and --with-plugin-path. I guess you mean that I need to make sure that plugindir=/usr/lib/htslib right? There is no need to patch configure.ac to alter this. Just add --with-plugin-dir='$(libdir)/htslib' as another configure option. I see Debian policy at last now blesses FHS 3.0, which includes libexec. However you may not wish to be in the vanguard of this, so that /usr/lib/ARCH/htslib would indeed appear to be the existing-Debian-style appropriate place under /usr. For /usr/local, any third-party instructions are likely to recommend installing their plugin into /usr/local/libexec/htslib, so I would recommend configuring with --enable-plugins --with-plugin-dir='$(libdir)/htslib' --with-plugin-path='/usr/local/lib/htslib:/usr/local/libexec/htslib:$(plugindir)' as being the most flexible for your users. (These directories are just scanned for files matching hfile_*.so; it is not an error if any of them does not exist.) BTW it looks like htslib-s3-plugin.7.gz has ben placed in libhts3 basically by default, although that is the right package for it. IMHO that would also be the right package for man5/*.5.gz as these are man pages aimed at users (not just developers) but YMMV. How can I verify / test the correct setting? By observing the -DPLUGINPATH=… setting that goes past in the log when plugin.c is compiled; by running `strings` on libhts.so; or by seeing what directories are scanned via e.g. `strace htsfile foo:bar 2>&1|grep O_DIRECTORY`. Cheers, John
Bug#971542: Please enable HTSlib plugins
Control: tags -1 pending On Thu, Oct 01, 2020 at 02:15:48PM +, John Marshall wrote: > Source: htslib > Version: 1.11-1 > > I would recommend building HTSlib with plugins enabled. Doing this will > activate HTSlib's plugin mechanism so that the Debian-supplied libhts.so will > be able to use any other file access plugins that the user may have > installed, and will move e.g. the libcurl and associated library dependencies > to hfile_libcurl.so (which libhts.so will dynamically load) which simplifies > linking against libhts.a for other programs. This can be done by adding the > following configure options: > > ./configure --enable-plugins > --with-plugin-path='/usr/local/libexec/htslib:$(plugindir)' Please inspect https://salsa.debian.org/med-team/htslib/-/commit/88644ba8e4096302d996dae2a0399195e2e53819 (and also your hint to the pull request https://salsa.debian.org/med-team/htslib/-/commit/84fcfcfda2b0b89d743bc8adb617abdf5cc22d4b ) > See HTSlib's INSTALL file for details. Packagers such as yourselves should > set with-plugin-path thus so that plugins in both /usr/local and /usr will be > used; If Debian still folds /usr/libexec into /usr/lib or nearby, you may > wish to adjust both --with-plugin-dir and --with-plugin-path. I guess you mean that I need to make sure that plugindir=/usr/lib/htslib right? It is sensible to assume that this is granted by the fact that the library itself is installed under /usr/lib ? How can I verify / test the correct setting? Kind regards Andreas. -- http://fam-tille.de
Bug#971542: Please enable HTSlib plugins
If you do enable plugins, in 1.11 please also apply this patch: https://github.com/samtools/htslib/pull/1150
Bug#971542: Please enable HTSlib plugins
Source: htslib Version: 1.11-1 I would recommend building HTSlib with plugins enabled. Doing this will activate HTSlib's plugin mechanism so that the Debian-supplied libhts.so will be able to use any other file access plugins that the user may have installed, and will move e.g. the libcurl and associated library dependencies to hfile_libcurl.so (which libhts.so will dynamically load) which simplifies linking against libhts.a for other programs. This can be done by adding the following configure options: ./configure --enable-plugins --with-plugin-path='/usr/local/libexec/htslib:$(plugindir)' See HTSlib's INSTALL file for details. Packagers such as yourselves should set with-plugin-path thus so that plugins in both /usr/local and /usr will be used; If Debian still folds /usr/libexec into /usr/lib or nearby, you may wish to adjust both --with-plugin-dir and --with-plugin-path. Thanks, John
