Re: uploading libzstd...
On 04/21/2018 06:48 PM, Mattia Rizzolo wrote:
> On Sat, Apr 21, 2018 at 05:45:34PM +0200, Alex Mestiashvili wrote:
>> Let me please elaborate my point of view. libzstd is team-maintained,
>> and because I didn't see any changes in the copyright/licensing for the
>> new upstream versions I obviously didn't think on checking the
>> copyright. Especially taking into account that the package has already
>> been successfully uploaded multiple times.
>
> You prepared (and uploaded yourself) the update to 1.3.3, that's the
> last occasion an upstream release was imported. I kind of expect people
> uploading new upstream release to review their copyright and licensing
> status.
OK. Will be more careful in the future.
>>> I removed the hurd-i386 patch, according to the upstream bug report the
>>> actual issue has been fixed now (didn't test myself though).
>>
>> Upstream solved only part of the issue. One of the tests takes too long
>> or too much memory on hurd as far as I remember and the patch was
>> addressing this problem. The Forwarded header doesn't apply anymore for
>> the current patch but it was correct for the initial version.
>
> hurd-i386 has been failing with that patch as well, so something else is
> needed anyway.
> As a matter of fact, comparing the previous failure with the patch
> applied and this one, the error is exactly the same, so…
I guess it's a different issue introduced in 1.3.3.
>
>>> Then, the actual issue, the symbol files.
>>> Alexandre Mestiashvili: it's not acceptable to just happily remove
>>> symbols. I don't understand what happened as the git log of that file
>>> is noisy, but looking at a simple debdiff the following symbols
>>> disapperead:
>>>
>>> - ZSTD_initCCtxParams@Base 1.3.2
>>> - ZSTD_initCCtxParams_advanced@Base 1.3.2
>>> - ZSTD_resetCCtxParams@Base 1.3.2
>>>
>>> Where did they went? I can't sensibly upload something that is removing
>>> symbols (i.e. breaking the ABI, but it seems to me that it also break
>>> the API?) without changing SONAME or giving a proper explanation.
>>
>> My bad. It seems that I don't understand enough how to properly handle
>> symbols. I just was following the manual[0].
>>
>> I'd really appreciate if somebody would explain what should have been
>> done in order to generate symbols files in this case.
>
> It's not a problem of the .symbols generation process, but rather an
> upstream issue.
>
> Those 3 functions (ZSTD_initCCtxParams, ZSTD_initCCtxParams_advanced,
> ZSTD_resetCCtxParams) that were part of the public interface have been
> removed.
>
> So one of the following should happen:
>
> * the functions are reintroduced
> * the SONAME is changed
> * the SONAME stays the same but the name of the binary package is changed
> * the investigation on those 3 symbols is performed and is declared that
> those functions were not public in the first place and only leaked
> accidentally, furthermore no reverse dependency has been using them
>
>
> It's a so called ABI break, and that's the regular procedure that should
> happen in such cases.
> Although, I'm afraid I wouldn't know of any specific documentation
> (wiki?) page that you could look up to have some decent outline on how
> to handle them... Guess I learned this stuff over the years following
> along library transitions and other nasty situations ;-)
I see now, thanks a lot for the details.
>
>> No idea why the 3 symbols above have disappeared. Again I'll be really
>> interested to hear what I did wrong.
>
> The only wrong thing you did here was to overlook those 3 removal lines:
> as a rule of thumb lines from a .symbols file should be removed only
> when the SONAME is changed.
Now I got it, also opened an issue:
https://github.com/facebook/zstd/issues/1111
>
>> Also I am a bit surprised of the mentoring tone of the message. Thank
>> you for your work but why can't it be resolved by submitting bugs for
>> every single issue as for example Helmut did? Is that the importance of
>> libzstd?
>
> mhh, bug about unreleased, git only changes? :)
> Or what did you mean here?
Oh, I see, right, the last upload was rejected. All good now :)
Thanks,
Alex
Reply to: