Re: help with sleuthkit symbols
Hello,
> > I discussed this with Francisco and we decided to drop the symbols
> > file for sleuthkit, that is mainly because sleuthkit is in parts
> > written by Cpp, but also because the extra complexity on maintaining
> > such file is not worth it, considering the only package using
> > seluthkit's library is sleuthkit itself.
>
> Reverse Depends:
> libtsk-dev,libtsk13 4.6.5-1
> sleuthkit,libtsk13 4.4.1
> guestfsd,libtsk13 4.2.0
> libguestfs0,libtsk13 4.2.0
Hmm, apparently I missed libguestfs, but that's fine.
> Removing the symbols is a bad approach. Symbols are essential to watch
> ABI status. Is need to think about the current and future of the
> packages depending on the library.
Removing the symbols file is the recommended approach for cpp
projects, and I think there might be a misunderstanding with regards
to what they serve for, they are not essential to watch for ABI
status, we use SONAME for that, and each new release needs to be
checked regardless of the symbols file (this new release is one
bumping the ABI).
I understand they do help by optimizing shlibs to not so strictly
depend upon new releases, which I don't think takes effect when an ABI
bump happens (I'd be curious if that happens). But in general they are
a good-to-have thing, not essential, recommended not to have it with
cpp projects, and only to be made available by the maintainer if the
person really knows what they're doing (as all the symbols need to be
carefully checked).
>If the problem is only
> "symbols-file-contains-current-version-with-debian-revision", simply
> remove the revision digit from each line inside the symbols file.
As I mentioned before, this wouldn't be enough, a symbols file needs
to have each symbol checked, and in the case of sleuthkit, some
symbols are coming from the compiler and not sleuthkit itself
(sleuthkit currently has an RC bug because of this). I'm also
considering the maintenance cost of such thing, which would be not
ideal, so I consider it better to just drop the symbols control file.
For reference, you can take a look at a recent discussion about a similar case:
https://lists.debian.org/debian-devel/2020/07/msg00240.html
Regards,
--
Samuel Henrique <samueloph>
Reply to: