Re: stap libdwfl bug-compatibility requirements

[Roland McGrath <roland at redhat dot com>]

> > I don't propose to worry about preexisting systemtap sources being
> > freshly rebuilt against elfutils-devel >= 0.138.
> 
> As discussed on IRC, I suggest we do worry about this case.  One
> possible solution is to give the bug-fixed variant a new name and
> preserve the old one (perhaps only as hidden implementation exposed
> via symbol versioning):
> 
> old/deprecated: dwfl_module_build_id
> new/fixed:      dwfl_module_build_id_bits

I don't want to uglify the current and future sources with random renamings.

I'm not sure I follow your logic.  In the unlikely event that someone
should take old systemtap sources and build it against a new elfutils,
you'd like them to get a compilation error because the old name doesn't
exist.  They would surely be confused and report the problem, to which the
first answer (even from someone who didn't know this week's details off
hand) would be to suggest using newer systemtap sources before worrying
about the details.

I'd like not to worry about this unlikely case, the result being that this
hypothetical person would get systemtap built, and then if they are
actually using a kernel built with build IDs (older ld didn't support
producing them, older kernel sources didn't produce them, older
distributions' packaged kernels don't have them), they would see
"inconsistent build-id byte" errors from running systemtap modules on their
kernel.  They would surely be confused and report the problem, to which the
first answer (even from someone who didn't know this week's details off
hand) would be to suggest using newer systemtap sources before worrying
about the details.

Why do we want to bend over backwards for this difference in result?

On IRC you said that if we ignore this case we might as well ignore the
binary bug-compatibility via symbol versioning too.  I don't see how this
follows in the slighest.  Doing that would mean that unsuspecting users who
simply use either a package system or vanilla techniques (make install) to
update either elfutils or systemtap independently would have systemtap
suddenly break, yet have no indication that a coordinated tandem update was
required to avoid a regression.  (In this case, symbol versioning means
that no coordinated update is required if you update only elfutils, and
that if you update to a systemtap that expects the fixed libdwfl behavior
you will know by version set dependencies that a cooredinated elfutils
update is required to satisfy it.)  This is the situation that we should
have most sympathy with (whereas developers who build things themselves can
be expected to just build newer ones), and it's also the one that we can
prevent in a way that's not at all unsightly in the future API (only a
little bit so in some libdwfl internals that only elfutils maintainers ever
have to see).

> Systemtap does not use the other build-id-related functions, and this
> may have been the only one affected by the bug.

The bug was directly in that one function.


Thanks,
Roland