How to proceed with MiniDebugInfo

[Jan Kratochvil]

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.


Regards,
Jan