What's up with elfutils?

[John Reiser]

Ulrich Drepper wrote:
> If you don't want elfutils, don't install it.  Your choice.  But don't
> make judgments for which you don't have the information:

In this particular case, I have 7 years of more-than-casual experience
in this area of software for Linux and have produced ELF utilities used
by others (including elfvector, rtldi, tub, tunelfso), but have never
invoked any eu-* utility directly "by hand" or by script which I wrote.
I also have entered and tracked many BZ reports in related projects
such as glibc and strace, projects which share maintainers with elfutils.
So I believe that I have at least moderate information on the topic
of object file utilities and Fedora.

> - there are no known problems in elfutils.  At least none known to me
> and none in BZ (which aren't fixed).

Oh, but there are.  Part of Nicholas Miell's reason for posting was that
one of the BZ entries was fixed incompletely.  He has the evidence,
tried to get it considered through the BZ process, and felt stymied
because that process is not as open as he felt it should be.

> - the tools in elfutils compared with binutils are a) smaller, b) faster
> (several times, usually), c) less buggy, d) more featureful

Those conclusions are important to state explicitly.  [Where is the data?]

> - there are several tools which are not available in binutils which are
> in (wide) use

It always helps to give two or three specific examples.  Then
others who are interested can increase their knowledge of both
elfutils and binutils, which might lead to improvements in both
packages.  Besides "eu-strip -f" for creating separate .debuginfo
packages, what else is available in elfutils but not binutils?

> - there are several more tools which use the elfutils libraries
> (systemtap, frysk, ...)
> 
> - there are more libraries part of elfutils which are not yet installed
> because they are not finished yet

Would now be a good time for input [of all kinds, including even code]
from a larger community?

> - almost everybody who has ever worked on binutils will attest what a
> horrible mess it is.  it deserves nothing but to die since you cannot
> salvage the disaster.  

I agree that binutils is extremely poor software.  However, binutils
does cover more than the 10 architectures covered by elfutils [alpha,
arm, i386, ia64, mips, ppc, ppc64, sh, sparc, x86_64.]   Elfutils
certainly covers the most important archs, but not every one;
for instance: m68k.

> Using an intermediate format which is not ELF not
> only adds overhead, it also means that there will always be cases when
> information is lost in one of the transformations.  This all is
> especially true when it comes to DWARF handling.
> 
> - it is certainly is my goal to finish the last gap in the tools vs
> binutils.  So at that time it would be a _possibility_ to drop binutils.
> 
> 
> But I think this is not really the main resentment.  People complained
> that there is no public CVS?  Why should there, you have all the
> sources.  Releases are made regularly after every major change (given
> the constraints of the package maintainer).  Other complain there is no
> release as tarballs.  Very simple, I consider tarballs to be the wrong
> form.  To guarantee consistency one needs something like src.rpm.
> Another complain is that there is no mailing list.  Well, you can create
> a mailing list whenever and wherever you want.  But one way or another
> you cannot force me to take time to read all the extra traffic.  I've no
> time for that.  Bugs can be filed in BZ and will be handled if necessary
> and reasonable.  And yes, we cannot except outside contributions.  Still
> not.  This is a problem with our legal department who still hasn't set
> up a mechanism which allows us to accept assignments.  And that's
> necessary, the code is copyrighted by me and Red Hat.

Part of my reason for entering and prolonging this thread is to increase
the documentation for elfutils.  Eliciting Ulrich Drepper's remark:
  > - the tools in elfutils compared with binutils are a) smaller, b) faster
  > (several times, usually), c) less buggy, d) more featureful
counts as a success, which would be even more signficant if accompanied
by some data to substantiate claims.  I even made a deliberate mistake
in using "rpm -qR" which Nicholas Miell pointed out should have been
"--whatrequires" instead.  I believe that the output (which indicates
uses by rpm and rpm-python), and Ulrich Drepper's remarks about Red Hat
legal department and copyrights, reveal significant new information
to the Fedora community about the reasons why elfutils is the way it is.
Elfutils is effectively part of RPM.  Elfutils is a part of the Red Hat
"crown jewels," which confers special status on elfutils.

--