From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.sergiodj.net (mail.sergiodj.net [167.114.15.217]) by sourceware.org (Postfix) with ESMTPS id EC9C2395A422 for ; Thu, 2 Jun 2022 19:32:49 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org EC9C2395A422 Received: from localhost (unknown [IPv6:2607:f2c0:ed84:8f1:5e89:96cc:d0c4:96ca]) by mail.sergiodj.net (Postfix) with ESMTPSA id 2E15CA016F; Thu, 2 Jun 2022 15:32:49 -0400 (EDT) From: Sergio Durigan Junior To: "Frank Ch. Eigler" Cc: elfutils-devel@sourceware.org Subject: Re: debuginfod & Debian source packages References: <87tu93kdle.fsf@sergiodj.net> <20220602182627.GA8520@redhat.com> X-URL: http://blog.sergiodj.net Date: Thu, 02 Jun 2022 15:32:48 -0400 In-Reply-To: <20220602182627.GA8520@redhat.com> (Frank Ch. Eigler's message of "Thu, 2 Jun 2022 14:26:27 -0400") Message-ID: <87mteukgin.fsf@sergiodj.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-3.7 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: elfutils-devel@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Elfutils-devel mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2022 19:32:51 -0000 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/