On Wed, 29 Jul 2020, Eriberto wrote:
> IMHO "is hard to maintain" is not a good argument. However...
FWIW I agree with Samuel that there's a trade-off to consider and
maintainability is among them. I wrote the symbols file support
for dpkg and I agree that it's not necessarily a good idea to use
i
IMHO "is hard to maintain" is not a good argument. However...
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
> > seluthki
Em qua., 29 de jul. de 2020 às 15:51, Samuel Henrique
escreveu:
>
> Hello Team,
>
> 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 fi
Hello Team,
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
Hi team,
I tried to generate symbols for libtsk19 from sleuthkit 4.9.0, the changes are
in "fvcr/libtsk19" branch, I found lintian
symbols-file-contains-current-version-with-debian-revision and I didn't know how
to solve it.
I generated the symbols, after the package was built, I did it like thi
