Control: clone -1 -2 -3
Control: retitle -1 htslib: please do not package cram/*.h headers
Control: severity -1 important
Control: summary -1 cram headers are considered private and other projects
shouldn't be interested in them
Control: retitle -2 htslib: please revert pkg-config change in
fix_pkg-config.patch
Control: summary -2 HTSlib's convention is that its headers are included via
#include <htslib/sam.h> etc, to avoid confusion with any other packages'
headers named sam.h. So a Cflags value of -I${includedir}/htslib is incorrect.
Control: outlook -2 This was done for libseqlib's sake: libseqlib needs to be
patched/fixed instead to work correctly with an unpatched htslib.
Control: retitle -3 htslib: please do not package htslib*.mk makefile fragments
Control: summary -3 These provide rules and dependencies that are useful when
building client software against an in-development HTSlib source tree, so
should not be used by anything when htslib is in a packaged format.
Control: outlook -3 debian/changelog suggests these are installed for
bcftools's sake. If these are needed when building bcftools against an
installed HTSlib, either you are configuring bcftools incorrectly or there is a
bug in bcftools.Hello everybody! So, I'm splitting this bug in multiple parts, because they are different things, that need different actions and some even changes in external packages, and they definitely need not to be done in one shot. They also have different severity for how Debian is concerned (https://www.debian.org/Bugs/Developer#severities). Please look up the appropriate number (https://bugs.debian.org/src:htslib) that got assigned to each issue and carry on separate conversations in the appropriate bug because they really are orthogonal. Consider also changing the subject for the first reply. On Wed, Nov 08, 2017 at 12:31:47PM +0000, John Marshall wrote: > There are several packaging infelicities in testing/unstable libhts-dev: Thank you so much for rising this issue. Whilst I'm not directly involved in htslib and related packages (I got poked because I forced a slighly broken version of pysam through just to complete the python3.5→python3.6 transition), I can tell you that is very very helpful whenever upstream involves himself in the distribution, and there is an healthy cooperation between us and them. Sadly most of the time this is not true (and I believe that's the source of all there is in this bug: somebody not even bothering asking you for changes due to their past experience with other developers). > 1. The cram/*.h headers are private and should not be packaged Let's track this in -1 (i.e. this very bug) > 2. debian/patches/fix_pkg-config.patch is incorrect Let's track this in -2. > 3. The htslib*.mk makefile fragments should not be packaged Let's track this in -3 > In general, upstream's "make install" rule reflects what upstream > thinks should be installed. If you find yourselves desiring to > install other things too, it would be good to contact upstream so > that a solution can be reached that fixes the problem for everyone. YES. I wholeheartedly agree with this. I just hope whoever find themselves doing it in the future will think about it :) Also, if you see something else is off in our package please file a bug report! Thank you again for report and for caring about Debian! ps: I know I used some commands above that most people don't even know about. If you feel like you are not supposed to understand them, then probably you indeed need not :) -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
signature.asc
Description: PGP signature
