Hi Diane and everybody, Le Tue, Nov 07, 2017 at 05:09:34PM -0800, Diane Trout a écrit : > > I do think we should bring back the symbols file
I think so too. Symbols file are strange to work with because their update usually goes through a build failure that outputs a patch, which is not very intuitive. And then the patched symbols file has to be edited to remove the Debian minor version, otherwise it complicates backports etc. Perhaps it can be simplified, better explained and streamlined. In any case, I think that for the htslib it is worth the effort. > I was wondering if we should split the cram headers into a > libhts-private-dev so we can at least track what is depending on the > non-public api. An ideal solution, and I understand that it may not be easy, would be to make the upstream users of htslib talk with the htslib developers, so that they can implement what they want to without needing to access private functions. I think that it would fit the aims of both sides. > I did realize that my thought about updating the SOVERSION might be > wrong because I was just looking in the source tree for the removed > functions but I should have been checking the public header files. Indeed, packages using private functions need to have a tight dependency on the htslib (unless we are very confident that there are regression tests that cover this area of the code). Packages that are more well-behaved can infer their dependency through the (to be re-added) symbols file. Have a nice day, Charles -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan
