Proposed F18 feature: MiniDebugInfo

[Jan Kratochvil]

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
>   packages.

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
elsewhere.


> 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.


Thanks,
Jan