#1369 packages should disable internal crash handlers and depend on ABRT
Closed None Opened 9 years ago by sharkcz.

= phenomenon =
There are packages that include their internal crash handlers and the handlers usually work only on a limited set of architectures. The value of a distribution is in integration and it should mean that ideally all application will use a crash handler common to all apps, in our case it should be ABRT. I'm aware that ABRT is still not in ideal shape, but having each app an own crash handler is worse in my opinion.

A recent case is qdigidoc which includes google-breakpad which builds only on primary arches.

= background analysis =

= implementation recommendation =
A recommendation should be added to Packaging Guideline stating that internal crash handlers should be disabled.


To clarify, you simply want a recommendation added and not an explicit rule forbidding internal crash handlers correct?

I'm OK with a recommendation, but I'm concerned that anything beyond that is somewhat undesirable. Some packages my not be able to disable internal crash handlers without patches and others don't really pose a problem in regards to ABRT. I think Firefox actually uses google-breakpad for its own crash reporter, but ABRT still seems to get coredumps there (at least on F20).

Replying to [comment:1 jwboyer]:

To clarify, you simply want a recommendation added and not an explicit rule forbidding internal crash handlers correct?

correct, to make a point which the maintainer should think about, like "Do we really need a new crash handler? Wouldn't ABRT do the same or better?"

This topic will be discussed at FESCo meeting on Wednesday 2014-11-19 on 18:00 UTC.

Replying to [ticket:1369 sharkcz]:

= implementation recommendation =
A recommendation should be added to Packaging Guideline stating that internal crash handlers should be disabled.
(From earlier:)
The value of a distribution is in integration and it should mean that ideally all application will use a crash handler common to all apps, in our case it should be ABRT.
This would rather suggest that the guideline should recommend making sure ''ABRT is used'', not ''other handlers should not be used''.

But then that would not help us avoid the work of porting google-breakpad ☺

Replying to [comment:2 sharkcz]:

Replying to [comment:1 jwboyer]:

To clarify, you simply want a recommendation added and not an explicit rule forbidding internal crash handlers correct?

correct, to make a point which the maintainer should think about, like "Do we really need a new crash handler? Wouldn't ABRT do the same or better?"

So I have (foolishly?) said the following a few weeks ago:

I will no longer tolerate/support any packaging guideline changes which, without expanding Fedora to an entirely new ecosystem/use case, add manual packaging or package review work. We are software developers, and the way we solve problems in our area and in this century is by writing software.

Would it be possible to add a rpmlint or fedora-packager check for the known offenders (google-breakpad, are there others?)?

Replying to [comment:1 jwboyer]:

I'm OK with a recommendation, but I'm concerned that anything beyond that is somewhat undesirable. Some packages my not be able to disable internal crash handlers without patches

I don’t think having to patch should stop us, as a matter of principle. If we need a better or more integrated distribution, touching the code is inevitable.

Replying to [comment:6 mitr]:

Replying to [comment:1 jwboyer]:

I'm OK with a recommendation, but I'm concerned that anything beyond that is somewhat undesirable. Some packages my not be able to disable internal crash handlers without patches

I don’t think having to patch should stop us, as a matter of principle. If we need a better or more integrated distribution, touching the code is inevitable.

Oh, I agree there. But if we're making it a requirement, we're now adding yet another thing package maintainers MUST do and some of them will certainly not be capable/willing to do it. That is why I was making sure it was a recommendation, not a rule. I have nothing wrong with Fedora carrying the patch if someone wants to add it to better integrate.

Replying to [comment:7 jwboyer]:

I don’t think having to patch should stop us, as a matter of principle. If we need a better or more integrated distribution, touching the code is inevitable.

Oh, I agree there. But if we're making it a requirement, we're now adding yet another thing package maintainers MUST do and some of them will certainly not be capable/willing to do it.

I agree that this can happen but I don’t think this should stop us ''either''. Such package maintainers can learn to write the code themselves or ask for help their sponsor or the wider community.

Note that the package maintainer has already had to learn to write shell scripts and the RPM syntax (used almost nowhere but packaging), so it hopefully is not too much to assume that they ''can'' learn to write code in other languages.

OTOH not being able to impose any requirement that might require creating patches would be a serious limitation on how much integration we can do.

(Yes, this is a tradeoff and might cause us to loose some packages if the maintainers in question have little time or interest in that kind of integration work.)

Replying to [comment:2 sharkcz]:

Replying to [comment:1 jwboyer]:

To clarify, you simply want a recommendation added and not an explicit rule forbidding internal crash handlers correct?

correct, to make a point which the maintainer should think about, like "Do we really need a new crash handler? Wouldn't ABRT do the same or better?"

So I have (foolishly?) said the following a few weeks ago:

I will no longer tolerate/support any packaging guideline changes which, without expanding Fedora to an entirely new ecosystem/use case, add manual packaging or package review work. We are software developers, and the way we solve problems in our area and in this century is by writing software.

Would it be possible to add a rpmlint or fedora-packager check for the known offenders (google-breakpad, are there others?)?

Good question and I understand your point. For the particular case of google-breakpad it already violates the No Bundled Libraries rule. IMHO it should be feasible to add such check into eg. rpmlint. Then there can be comprehensive libraries like wxWidgets who can provide crash handlers (I disabled it long time ago), other application may use glibc backtrace() interface or just install own SIGSEGV handlers. And there might be other means how to implement crash handlers.

Don't all kde packages send crashes to a kde based service?

Yes (to KDE Bugzilla), and that's how it should be. !DrKonqi can report crashes directly upstream, which is where they ultimately need to go. With ABRT, we would have to sort through all the crash reports and forward them upstream (because the average ABRT user will not do it for us even if we ask him/her), and we really don't have the resources to do that. And to the best of my knowledge the KCrash crash handler which calls !DrKonqi works just fine on secondary architectures. (It just intercepts the signals and then invokes GDB on the executable itself to get a backtrace.)

In light of the recent privacy discussions, let me also clarify that !DrKonqi only sends complete bug reports (including the backtrace) to KDE Bugzilla and only on the user's explicit request. No other data is uploaded to KDE servers. (For backtraces, debugging information can be downloaded to the local machine, again only on the user's explicit request.)

So it really does not make sense to disable KCrash in favor of ABRT.

As for the Google Breakpad portability issue, I'd suggest ifarching the dependency rather than disabling it entirely. As a general rule, when an upstream crash handler exists, this is really almost always a better thing to use than ABRT, which can only report to our downstream Bugzilla and not to the upstream developers, who are most able to fix the crash. (And yes, if they ship such a crash handler, that implies that they are interested in getting those crash reports.)

There was a lengthy discussion on FESCo meeting and the decision was postponed to next week.

I shall also mention that the upstream crash handlers typically upload a lot less privacy-sensitive information than ABRT can upload. E.g., ABRT can upload core dumps to the retrace server, and it can attach pretty much everything to the bug: core dumps, environment variables (see also the discussion on the devel mailing list), some log files, etc. So it's a lot more likely that a user accidentally leaks private information with ABRT than with any of the other crash handlers.

Let projects continue to do as they see fit (+6,0,0)

Login to comment on this ticket.

Metadata