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