Hi Panu, On Wed, Jun 05, 2024 at 09:26:14AM +0300, Panu Matilainen wrote: > On 6/4/24 21:43, Frank Ch. Eigler wrote: > >dvlasenk wrote: > > > >>[...] Do you understand how many fetches of debuginfo will be > >>attempted by e.g. a kernel build tooling when it runs readelf on 8000 > >>freshly built modules _for every kernel build_? How slow it is? > > > >If remote debuginfo is not needed for these particular readelf > >invocations, then the tools should not be making debuginfod calls. > >Can you help identify examples? > > > >>Now various tools need to forcibly unset the variable to stop this > >>madness. > > > >The defaults are set with normal developers in mind. > > The problem is that nobody expects a tool this low-level to do > internet lookups, and silently at that. It's like 'ls' suddenly > started looking up stuff from the net *by default*. > > And, not just interactive use but scripts too, scripts that existed > years or even decades before this thing and cannot possibly expect > such activity. Like the case of > https://bugzilla.redhat.com/show_bug.cgi?id=2079600 This surprises me. You are right that nobody would expect readelf -d (to get the dynamic table entries) would use debuginfod. And it indeed doesn't. Might this just have been an old bug in binutils since fixed? > And, it's made much worse by the packaging which means you cannot > just remove the package and be done with it, because so much > important tooling links to it. If the library and the configuration > to actually enable it were split between different packages, it'd be > less offensive at least. I am sorry you are so offended by the packaging, but nobody has suggested this before. Please do file a bug with this suggestion if you think it makes sense to split the default /etc files and the actual debuginfod-client library. Cheers, Mark -- _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
