On Tue, Apr 24, 2018 at 05:37:00PM +0200, Alex Mestiashvili wrote: > > 1. check that no rdeps are currently using those symbols (because this > > is C and there is nothing preventing packages from using them if they > > really want to…) > > No rdeps use these symbols, a quick and dirty check: > https://paste.debian.net/1021816/
Good! > > 2. check if it is possible for those functions to e.g. be defined as > > static or something else that would prevent them from being exported > > this will involve patching the code and maintaining the patch over > releases. So I am a bit skeptic about it. Well, why do you assume you'd have to "maintain the patch over releases"? It's obviously something that should be done upstream and committed there. I've also elaborated on this in the upstream bug https://github.com/facebook/zstd/issues/1111 > > 3. I fear a similar fate will also happen to all the other functions > > defined similarly, so I wonder if at least some kind of comment > > should be added to the .symbol file for those symbols. > > as far as I see the symbols introduced in 1.3.4 Both CCtx and DCtx are > for experimental compression and decompression and are not used by default. Also in another email you wrote this "by default" that I can't really understand what it means in a context like this. > May be it makes sense to tag them as optional? The 3 missing are not > really missing, just renamed, so marking them as #MISSING: is also not > right isn't? the "#MISSING:" is not a marker, just a way dpkg-gensymbols highlights them, people are not really supposed to actually add such lines to their .symbols file. And "rename" is not a thing when talking about ABI: if a symbol is "renamed" and a binary tries to look for it, it will just segfault, it won't say "oh, but it's only renamed" :) Marking them as optional will make dpkg-gensymbols not bother when they are removed, it's usually done to cover stuff that are leaked by the compiler (for example, ISTR a case where g++ leaks something related to the implementation of string…) or I also remember some cases involving c++ templates…, but anyway are not expected to always be there, they may just disapperare when built with a different version of gcc. That's not really the case here. I was more thinking of a pure comment, highlighting how those symbols are there "by accident" and that they are "mostly fine" to be removed in a future version, while waiting for a more proper management of those symbols as per point 2 above. Something like: (should only be used when static linking)ZSTD_CCtxParams_init@Base 1.3.4 Nonetheless I recommend doing a check like the one you did at point 1 every time such symbol is removed: it's not like history isn't full of software using some API in a way that it wasn't meant to (in which case, a proper course of action could be to add a versioned Breaks on the package using it). -- 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
