[Test-Announce] Fedora 18 Beta Test Compose 8 (TC8) Available Now!

[Kevin Kofler]

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