Le mar. 16 sept. 2025 à 09:28, Guillem Jover <guil...@debian.org> a écrit :
> 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). > Not sure about that, because of "abidiff uses by default, debug information in DWARF format" and I read that that format is architecture independent ? It has also some debuginfod integration. > 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 > >
