Kevin Fenzi wrote:
> FESCo decided the benefit to always having mini-debuginfo
> available outweighed the downside of increased space.
What benefit?
* MiniDebugInfo contains only basically the same information already present
in the dynamic symbol table of shared objects! (GDB can already use the
dynamic symbol tables, it doesn't need a redundant copy of the data.) The
only additional information you get is the location of hidden symbols and of
symbols in executables. This is a huge penalty for that small additional
information.
* MiniDebugInfo does not contain necessary information for good backtraces,
inluding line numbers (which were proposed as an option by the feature
owners, but which would have made the bloat almost an order of magnitude
worse!), locations of function arguments etc. The ABRT folks said they were
going to treat MiniDebugInfo the same as none at all.
* For people who really do not want to download debugging information,
there's the ABRT retrace server.
WHERE is the benefit of MiniDebugInfo?
> I don't recall anyone saying "Make your image larger then, we don't
> care".
Maybe not these exact words, but that's the essence of what the people
voting for the "feature" said.
I've read several comments of the "Who cares about CDs anymore?" type.
> Your possible options are:
>
> a) target a larger size (which is what you have done?)
As I said, we were basically told to do so.
> b) ask FESCo to reconsider, but you probibly want some kind of NEW data
> for that, because without that it's just likely to end the same way.
That's what we did:
* I pointed out that the relative numbers given on the feature page are
misleading because they compare compressed debugging information with
uncompressed stripped binaries, whereas after compression (i.e. on the
images, i.e. where we actually care about size), what matters is compressed
vs. compressed (or uncompressed vs. uncompressed), compressed vs.
uncompressed is entirely irrelevant. In particular, the statement on the
feature page "To minimize space use (on the installed system but also on the
installer medium) we've decided to only go with the compressed symbols." is
incorrect and deceptive, compressed symbols do NOT help the size on the
installer media at all because both the live images and the RPMs on the DVD
are already xz-compressed (in fact, compression is likely making things much
WORSE because the redundancy between the MiniDebugInfo and the dynamic
symbol tables cannot be exploited for compression that way). That was
ignored (and the false advertising was not held against the feature owner
and is still on the feature page).
* The OLPC maintainers pointed out that the size hit was also a big issue
for them and that they had no way to increase their target size without
desupporting all the XO 1.0 devices.
* The ABRT developers made clear that the MiniDebugInfo was of no use for
them.
* Jan Kratochvil, the expert in matters of debugging information, also
expressed doubts about the usefulness of MiniDebugInfo on this list.
None of this was given sufficient consideration.
> c) Drop some more stuff from the live to get it back under 700mb.
That'd be A LOT of stuff to drop given the 10% (!) bloat from this
"feature".
Kevin Kofler
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
