Re: build id computation

[Roland McGrath <roland at redhat dot com>]

> In my opinion what counts is what people are doing and saying, reads .text and
> .data. I'm not even convinced if it is important where they say it, reads
> directory or file name.

Then you have no interest in build-id and you should not use it.
Feel free to checksum the stripped file and use that for whatever you like.
That has nothing to do with the purposes for which build-id exists.

> I understand the motivation behind debugedit but I doubt that producing two
> different build ids depending on the _builddir setting is correct. 

As I explained, it produces the same build ID for a repeated build with two
different _builddir settings.  As I just said, this is the only reason that
debugedit recomputes the ID.

> In my opinion, changing the pathnames embedded in the debuginfo is not
> semantically changing the ELF executable itself.

I said the semantics of the unstripped file.  That certainly includes the
semantic content of its DWARF sections.  If you are talking about something
else, like the run-time effect of the stripped file, then you are just
playing semantics with which semantics we're talking about.

> If I understand you correctly you also want to include the sources into the
> checksum. Since that doesn't seem to work today, I think that should be done
> externally. Otherwise you would run into problem reproducing builds anyway.

No, I don't think it's worthwhile to worry about the checksum of the
source.  In published debuginfo--the only case build IDs are really
useful--one uses canonicalized source directory names that include the
package name and version.  The list of those source file names constitutes
a sufficiently unique signature from which to find the right sources.

> I'm thinking about situations where autogenerated code is involved but the
> higher level source hasn't changed. Probably you want to have a reproducable
> build id in this cases as well.

If the source and environment really haven't changed, then the generated
source comes out the same twice in a row.  If it differs, then there is
something different about the build and it's correct that it get a
different build ID.


Thanks,
Roland