> I've also elaborated on this in the upstream bug > https://github.com/facebook/zstd/issues/1111 Very good. Thanks! > >>> 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. These functions are part of experimental API which can break and I expect that people will not use it until they really want to. But I understand your point and agree that they shouldn't be exported at all. > >> 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. Ok. > 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" :) That's totally clear :) > > 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. Ok, I see. > > 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). So far I added the comment to the 3 renamed. I expect that more symbols will disappear after upstream fixes visibility of experimental functions. But this time I'll be prepared :) Thank you a lot for the detailed answers! Really appreciate that. Alex
Attachment:
signature.asc
Description: OpenPGP digital signature