How to proceed with MiniDebugInfo
jan.kratochvil at redhat.com
Thu May 24 14:19:15 UTC 2012
On Thu, 24 May 2012 15:34:28 +0200, Alexander Larsson wrote:
> 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?
If your feature does not solve any problem it is just a bloat.
> * Write backtraces to syslog on coredumps
backtrace is overloaded here. Minidebuginfo provides only bare unwinds.
> * Allow ABRT to do better duplication matching (the ABRT developers even
> want minidebuginfo!)
"do better" is too ambiguous and probably not right. Duplication matching can
be always done server-side. Minidebuginfo may give less load for ABRT servers
for example, this does not match the "do better" phrase.
> * 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.)
I do not limit possible solutions only to retrace servers. Cores can be
backtraced even locally with full quality by (y) or (z) from my last mail.
> * Do system wide profiling and tracing without having to install a lot
> of debuginfo.
But a poor quality again, there won't be line-specific data for example.
> * 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,
debuginfo-install does everything on its own, user does not have to care.
> or when you don't have a network connection to get
> debuginfo packages.
This is the only valid point and pre-requisite of all your claims. But I do
not find a machine without network connectivity to be useful for anything.
> So, does these advantages outweigh the cost?
Sure in no way.
More information about the devel