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