How to proceed with MiniDebugInfo

Alexander Larsson alexl at redhat.com
Thu May 24 13:34:28 UTC 2012


On Thu, 2012-05-24 at 14:46 +0200, Jan Kratochvil wrote:
> On Thu, 24 May 2012 11:07:06 +0200, Alexander Larsson wrote:

> There are many ways how to solve this problem, unfortunately nobody knows what
> is your problem, there are too many close but still different problems in this
> basket.  You have delivered solution without stating the problem first.

I don't think there has to be a specific "problem". In fact, I think
Fedora shouldn't really care what *my* problem is. What is interesting
is: I have this feature; It has a certain cost (increase in size) and it
gives certain features. Is the price worth the features it gives?

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.

So, does these advantages outweigh the cost?



More information about the devel mailing list