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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
