On Oct 18, 2014, at 5:56 PM, Colin Close wrote: >> I am compelled to say: >> >> 1) building with -g generates symbols, no matter whether you choose to strip >> or generate *debiginfo*. Very little time will be saved. >> >> 2) DWARF, not *debuginfo*.rpm is responsible for bloat that afects bandwidth >> and resource usage. >> >> You need to fix DWARF generation and the design of (ab-)using *.rpm >> packaging as a mirrored download distribution mechanism to meaningfully >> "solve" the issues you have stated. > Jeff, > I am curious about this statement because I think you may have hit on > something here. Thinking about this the biggest resource saving would > probably > be made by not mirroring the debug packages but retaining them on the primary > mirror. I had no idea that DWARF did not live up to it's name:).
The historical problem with "bloated" *-debuginfo packages has to do with essentially data normalization. Each and every compiled file duplicates (or duplicated) the debugging info. You can see the issue by looking at the size of kernel-debuginfo packages (if they are still being produced). At one point in time, kernel-debuginfo weighed in at 500+Mb. I don't know what the current state is in DWARF. The underlying problem is very hard to solve, I'm sure there have been many incremental improvements. The debuginfo bloat is fine for local debugging but doesn't "work" for distribution because other issues like bandwidth/storage persistently become important. Other means of distributing debugging symbols (than *.rpm) need to be devised. Meanwhile, dropping debugging symbols will have a significant development/QA cost, and -- as has been pointed out -- a significant everything rebuild cost (if attempted only for the "final" distribution). Incrementally building +debuginfo, but mirroring internally/privately, is likely the cheapest cost <-> benefit. Other solutions, like using a Big Data NoSQL! distribution are possible too, but would require some thought and design. hth 73 de Jeff _______________________________________________ OM-Cooker mailing list [email protected] http://ml.openmandriva.org/listinfo.cgi/om-cooker-openmandriva.org
