Hi! On Mon, 2025-09-15 at 17:45:15 +0200, Simon Chopin wrote: > On lun. 15 sept. 2025 17:35:26, Jérémy Lal wrote: > > following a remark done by someone during t64 transition, > > I wonder if abigail-tools could be a better way to track symbols changes ?
Matthias Klose during DebConf25 suggested to me to look into this to integrate into dpkg for symbol/dependency tracking purposes. And while I had previously briefly looked into it for ABI tracking purposes, I don't think I had considered it for the symbol/dependency aspect at that point. > > A package maintainer can use it like dpkg-gensymbols, except the format > > is XML, and it seems to be able to deal better with C++ changes. > > > > Anyone knows if that's a reliable tool for that purpose ? > > I have often wondered about doing something like this, as I think > abigail would be great at detecting ABI breaks. I *think* it is used in > Fedora. I think using abigail for ABI tracking would be great, yes, but I don't think it looks like a good fit for dependency tracking TBH. Its XML representation seems too detailed (which is needed for its ABI tracking), which means you really need to build the package on each architecture, then fetch the generated XML, add them to the packaging, and upload again. And it looks like each XML file is going to be arch specific (besides embedding the arch specific types, it will embed multi-arch qualified header locations etc, unless there's a way to track some kind of more generic template representation). To me it seems like this would be way better as a service, similar to lintian, where after you have uploaded a package, the ABI XML representation is extracted and compared against the previously built one on a db. And if there's an ABI break this could then be also used to gate migration to testing, although I guess we'd need some escape hatch or overrides mechanism, in case one knows a possible ABI breakage is a non-issue (or affects only supposedly private symbols, or similar). > However, symbols files are also used for another purpose: generating > versioned dependencies when you start depending on a newer symbol. In > order to replace gensymbols, you'd want to make sure it could also do > that. The current dpkg-gensymbols support could/should be improved, several of the modifications done for the KDE fork should be merged back (like its subst support, but not in its current form), the problem has been that this needs some underlying support for generic C/C++ ABI tracking, defined as part of the arch definitions and also to namespace them for language family or runtime. And whether those type definitions should be carried by dpkg itself as part of its arch ABI definitions, or by the toolchain (gcc/libc) packages, which have been known to switch underlying representations of types in the past, for example. Thanks, Guillem
