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.
> > 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…
> > 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 ;-)
> 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.
> 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?
--
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 `-
Attachment:
signature.asc
Description: PGP signature