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.