Proposed F18 feature: MiniDebugInfo
jan.kratochvil at redhat.com
Mon May 7 15:36:07 UTC 2012
On Mon, 07 May 2012 17:15:17 +0200, Alexander Larsson wrote:
> * They don't work offline, or before/after the network is up
> * Its problematic to use a retrace server during early boot, or e.g. in
> non-session apps like a daemon
/var/spool/abrt/ stores them for later GUI upload, it already works this way.
> * There are privacy issues with sending the users coredumps to some
> server on the internet
As whole Fedora is built by the Fedora Project and Retrace Server is also run
by Fedora Project this is non-issue. There can be already inserted trojan
uploading of any private info in the shipped binaries.
Somehow I agree it is a valid point.
But the people concerned about this level of security are so few they can
afforrd downloading full debuginfos (like I do).
> * They don't work for site-local packages, or scratch builds of fedora
With locally built packages I believe the person is already a developer with
full debuginfos installed.
But I find this as a valid usecase missed by Retrace Server.
> * They require some server to store every build of every fedora package
> forever, and sync new builds from the buildsystem there.
This is already done anyway; already provided.
> * If some organization doesn't want to send reports to the fedora
> servers they need to duplicate all debug info packages on their
> retrace server
Not so valid point, I believe current Retrace Server does not but it could
also download packages on demand.
This is more a problem existing Fedora infrastructure does not store old
builds so there is a need for persistent storage of everything on Retrace
Server primarily for that reason anyway.
> * They only work for ABRT, not if you're e.g. debugging something
> locally, or a user is reporting a backtrace with gdb
> * They can only be used for crash reporting, not e.g. tracing
> or profiling
Yes, I target only the ABRT use case. We can talk about non-ABRT use cases
> I think retrace servers are interesting, because when applicable they do
> allow you to get a higher quality backtrace, with full debug info.
> However, I think we should *always* have a baseline backtrace with at
> least function names, which is there when retracing isn't.
I do not find many reasons why "retracing isn't". If it really is not (is
not?) we should rather fix that.
> So, I don't think the existance of retracing servers is contrary to
> having minidebuginfo.
I agree but I see these minidebuginfo usecases (where ABRT Retrace Server is
not applicable) to be very limited (*).
(*) and IMHO therefore not worth the distro size increase.
More information about the devel