On Thursday, June 02 2022, Frank Ch. Eigler wrote: > Hi -
Hi Frank, >> I'm the maintainer of debuginfod.debian.net (currently offline due to a >> hardware issue :-/). > > O no. (And also, please consider upgrading your elfutils version, as > later ones have less pessimal behavior with long grooming ops.) I have to backport the new version to Debian bullseye, but yeah, this is on my TODO list. >> [...] >> I'm now thinking about an alternative solution to this problem. Debian >> source packages already contain everything needed to be indexed and >> served to debuginfo consumers; it has the full source code + all the >> downstream patches. It's represented by a .dsc file that can be fed to >> dget(1) which will download the source tarball and apply all the patches >> automatically. >> >> Do you think we can teach debuginfod to consume these files and do the >> right thing when indexing the source code of each package? [...] > > Interesting idea, but I'd throw it back at you thusly: does debuginfod > need to this itself on the fly? Other than perhaps a time/storage > tradeoff, is there some reason an auxiliary program couldn't do this > in the background? Take designated .dsc's, download, apply patches, > and assemble the patched sources into, well, any old random tarball > format? If someone(tm) were to write such a script, we could ship it > alongside debuginfod if desired. Sure, I believe an external script/program could do things behind the scenes without problem. > As long as the archive file name was a close match to the binary deb > file names, and as long as the constituent files were named with the > same paths as mentioned in the binary dwarf, debuginfod would gladly > take the result and serve from it. OK, this was going to be my next question. Out of curiosity, how would debuginfod invoke this external program? Thanks, -- Sergio GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36 Please send encrypted e-mail if possible https://sergiodj.net/
