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: - there are no known problems in elfutils. At least none known to me and none in BZ (which aren't fixed). - the tools in elfutils compared with binutils are a) smaller, b) faster (several times, usually), c) less buggy, d) more featureful - there are several tools which are not available in binutils which are in (wide) use - 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 - 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. 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. -- ➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
Attachment:
signature.asc
Description: OpenPGP digital signature
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
