Bug#874305: RFS: mitlm/0.4.2-1 -- MIT Language Modeling toolkit
On Sun, Sep 09, 2018 at 12:25:54PM +0200, Giulio Paci wrote:
> Hi Mo,
> thank you for your offer and review.
> Unfortunately I do not know when I will be able to handle these issues as I
> have very limited time at the moment.
>
> And the latest standards version is 4.2.1 .
>
> As you can see from git, the package as not been updated since a long time. As
> soon as I can work on it again I will update the package.
> Given the long time that has passed since my last update, during the last few
> months I have also thought about orphaning, but I am still hoping to find time
> in the close future.
No problem, just take your time. And thanks for your contribution to Debian!
> 2. why is the SOVERSION bump from 0 to 1?
> ------------------------------------------
>
> Has upstream bumped ABI/API?
>
> I do not remember the exact reason, but I confirm that SOVERSION has been
> bumped upstream as well.
Ok.
> The original upstream author is not active anymore, so I also act as upstream
> for this package.
>
> Besides, I'd suggest add symbols control file for this package such
> that ABI changes can be tracked more easily. One will obtain a symbols
> list from buildlog after creating an empty .symbols file and rebuild.
>
> I was never able to use symbols files with C++ ABI, as I always receive errors
> on architectures that are different from the one that I use to create the
> symbols file. Moreover I have also tried different approaches to track symbols,
> in order to guarantee that the ABI has not changed in any platform (e.g., if
> the API changes a parameter from int64 to size_t, the change is not always
> reflected in the ABI). In the end I gave up trying to track them. When I
> described the issue upstream, in many cases some of them simply started bumping
> SOVERSION at every release, just to stay on the safe side. Do you have any
> better strategy to solve these issues?
Indeed sometimes C++ symbols is a nightmare compared to that of C.
For a small C++ library one solution is to create different symbol
files for different architectures, i.e.
│
│ debian/libfoobar.symbols
│ debian/libfoobar.symbols.arm64
│ debian/libfoobar.symbols.ppc64el
│ ...
│
This can be done by abusing buildd a little bit -- e.g. uploading the
package with the amd64 symbols first, and then collect the symbol
patches from buildd for different architectures and create specific
symbol files for them. In this way the maintainer's burden won't
increase too much.
> Best regards,
> Giulio
Reply to: