On Sun, Aug 02, 2020 at 06:41:33PM +0200, Mark Wielaard wrote: > If it is convenient for Debian we can do a 0.181 release to make this > official.
Thank you for the offer. I don't think that anything (in Debian) links libdebuginfod at present. Therefore we'll just make the library and the program optional with one flag (pkg.elfutils.nodebuginfod is what I propose as build profile name). We can revise build profiles at a later time if the need arises. In general, I don't like stub libraries. Bootstrapping is hard and you can easily get it wrong. A failure at one step sometimes manifests much later. Therefore we compare bootstrap builds with native builds using diffoscope. Having a stub library would show up as a giant difference. I'm not saying this cannot be done. I just want to avoid doing it as long as we can. I actually wonder more about why debuginfod must be merged into elfutils. To the uninitiated, it would seem that building debuginfod entirely separate should be possible. Simply separating debuginfod into a separate tarball (and source package in Debian) would have eliminated the need for the profile and --disable-debuginfod and likely more. Doing so might be difficult on the upstream side though and I'm not sure whether splitting debuginfod at release time would be practical. Very likely, you do have reasons for maintaining them together. This kinda is the same situation with util-linux. Splitting the libraries into a separate source tarball would make bootstrapping easier. There seems to be a trend in fusing components together. This also happened to udevd and systemd. Helmut
