This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: stap libdwfl bug-compatibility requirements


> This elfutils bug - however resolved - will require systemtap to carry
> #if ELFUTILS or autoconfy "uglification" permanently.  So an argument
> based on aesthetics of a single function name is not very convicing.

It's an argument to set the standard for how compatibility is handled, and
then adhere to it.  That is, to handle it the same way it's handled in
every other library (whose maintainers worry about compatibility at all).
Your example would set the stage for repeating a willy-nilly recasting of
names every time there is a bug that could have been worked around,
depriving the API's users and designers any possibility of sound aesthetic
consideration in the choice of names that prevail in the future.

Systemtap can in future very well carry a simple "requires elfutils 0.138
to build" check, and use only the preferred clean interfaces of the day.
It is frankly extremely likely that future systemtap versions will employ
new elfutils library code that does not yet exist, and so will want to
simply require a yet later and yet cleaner version of the elfutils library
interfaces in the future.  Your claim smacks of hyperbole.  (For claims
about the hyperbole of "any possibility of sound aesthetic consideration",
you can just get straight to the smacking and I won't have any retort! ;-)

> I have no new suggestions.  I guess we'll just have to adapt to
> whatever you decide.

That is rather melodramatic.  You didn't respond to my proposals for
addressing all the cases I think warrant consideration.  If those are not
to your liking, they needn't necessarily be the solutions chosen.  Since
all you've mentioned is the treatment of this one case (the one least
important to users), I'll take it that you are happy with the rest.

If noone has anything different or more compelling to offer, I'll go ahead
with what I've described for the 0.138 release.


Thans,
Roland


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]