IMHO administrators would benefit much more from the minidebuginfo feature than developers. The advantage for admins is that for every crash the computer would also give a "name" of the crash. So it's no longer just "httpd: Core dumped.", but you get a unique sequence of functions (a "name") and you can talk about this particular crash with other admins (it's no longer just "our webserver is randomly crashing"), and search the Internet for other victims. It would be very cool if the bottom of the stack (last few functions) is printed to the terminal together with the usual "Core dumped." message. For developers, it is unappealing to attempt fixing a bug just from an ordered list of function names. Karel Alexander Larsson wrote: > Now, I don't want to repeat everything said before about what > minidebuginfo can do, but I'll give some short examples of things > that > are nice to have and hard to do well without local debuginfo. > > * Write backtraces to syslog on coredumps > * Allow ABRT to do better duplication matching (the ABRT developers > even > want minidebuginfo!) > * Always get some minimal level of backtrace quality, even for rpms > built locally or from other repositories which are not availible > on the retrace servers. (Assuming they are built on a F18 or later > which has this feature.) > * Do system wide profiling and tracing without having to install a > lot > of debuginfo. > * Help developers by always having at least some level of debuginfo, > even for e.g. uncommon dependencies that you don't typically have > debuginfo for, or when you don't have a network connection to get > debuginfo packages. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
