rfc/patch: user-agent distro-description for debuginfod http traffic
Wed Jan 8 19:36:00 GMT 2020
On Wed, Jan 08, 2020 at 10:11:25AM -0500, Frank Ch. Eigler wrote:
> > Eep. We really should pick up this info during runtime instead of
> > during build time.
> That's what I thought at first too. However, doing it at run time
> means doing work - a popen() etc. - over and over or saving in a
> locked global. Since on a normal machine, the distro doesn't change
> without elfutils also changing, it's practically a literal.
We are already opening some files to scan for cached files, open a
socket, download data, etc. I don't think one or two extra syscalls
are that much overhead.
> > We do want a reproducible build.
> Can you give an example? Bootstrapping a new distro version/arch?
Probably best explained at https://reproducible-builds.org/ most
distributions are participating.
> > And this will most likely produce wrong information if the package
> > build server is on a different OS or release than the OS/release it
> > is producing packages for. uname -sm might be "stable", but probably
> > not when cross- compiling.
> I wonder if the cross-compiled debuginfod-client case is worth
> worrying about.
I think it is.
> > But where does lsb_release come from? I don't have that on my
> > systems.
> BuildRequires: /usr/bin/lsb_release :-) It's a different package on
> different distros. And running at run time would make a Require:
> rather than a one-time BuildRequire:.
It looks like the new standard (since about 8 years) is os-release:
It looks like an easily parsable file format. The attached produces
some reasonable looking identification strings on a couple of my
systems out of the box:
Maybe something like that is usable?
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 1171 bytes
Desc: not available
More information about the Elfutils-devel