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