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>
