On 01/11/2011 04:54 PM, Denys Vlasenko wrote:
On Fri, 2011-01-07 at 15:29 +0100, Jiri Moskovcak wrote:
> This is the list of feature to complete for ABRT 2.0, once this list is
> finish we'll done with 2.0. The list is probably not complete, so please
> add anything you think is missing. I'd also like to ask you to add some
> comments about how far the feature (you're working on is) and what it
> depends on, so I can then make it into nice roadmap...
>
> = ABRT 2.0 Features (what we need) =
> ...
> /etc/abrt/conf.d/ directory (devels can drop there configuration for
> their packages)
> --> provide a way for maintainers to blacklist their packages without
> changes into abrt package
Let's perform a bit of brainstorming on this.
Fragment of current default /etc/abrt/abrt_event.conf:
# abrt-action-analyze-c needs package name, save package data first
EVENT=post-create abrt-action-save-package-data
EVENT=post-create analyzer=CCpp abrt-action-analyze-c
EVENT=post-create analyzer=Python abrt-action-analyze-python
EVENT=post-create analyzer=Kerneloops abrt-action-analyze-oops
A few ideas how to extend it to pick up config files from a subdir
so that other packages can add/modify post-create event handling:
(1)
[include] /etc/abrt/event.post-create.d/
- my idea was that we'd have a /etc/abrt/events.d/ containing files with
the same syntax as abrt_event.conf, so maintainers can override any
event they want
- one problem with this is how we decide whether to add the specific
event handler to the default one and where to use only the specific one
(2)
EVENT=post-create abrt-handle-crashdump -d "$DUMP_DIR" -e
"$EVENT" -c /etc/abrt/event.post-create.d/
(3)
EVENT=post-create for f in /etc/abrt/event.post-create.d/*
do
test -f "$f" || continue
abrt-handle-crashdump -d "$DUMP_DIR" -e
"$EVENT" -c "$f" || break
done
Relative pros and cons:
Proposal (1) - new directive "[include] DIR" or "include
GLOB_PATTERN" -
allows to statically determine whether a particular dump dir has
any defined "post-create" event handler(s) - config file parser can walk
included config files and find out whether there is a handler.
- I prefer this solution with a minor change - I would hardcode the path
into the config parser and wouldn't use the [include] directive (I don't
think we would use a multiple directories or am I missing something?)
For "post-create" event it's not that important, but
for "report[_FOO]"
events it is: client programs do this in order to determine which
report events make sense for a particular dump dir.
The importance of this depends on whether we envision packages to add
their own configs with handling for *reporting* events (as opposed to
"post-create" even and such). Do we?
- yes, we do, as this was part of the RFE(but discussed in other thread)
- real life use case:
- maintainer of evolution prefers all evolution bugs to be reported
and handled upstream
- he claims that it doesn't have any downstream patches
- he can negotiate reporting ABRT bug to upstream with upstream
- right now he spends a lot of time by just going thru Fedora bugs and
copying them to upstream bz
- if we enable
Proposals (2) and (3) are similar: instead of making config parser
more
complex, they use the power of modularity which new event-based
processing gave us.
They both need abrt-handle-crashdump to be extended with -c CONF_FILE
or -c CONF_FILE_OR_DIR option.
Another useful extension is to allow action to be written in multi-line
form, as shown in proposal (3).
On the minus side, they might look ugly. Do they look ugly to you?
What else we might want/need? Consider the case when packages can add
additional data-collecting steps, but they do not know *when*
this data-collecting should happen - immediately after crash
(post-create event) or at the point when user selects the crash
for reporting ([re]analyze events)?
Proposal (2) can handle this situation by "redirecting" one event to
another,
something like this:
EVENT=post-create abrt-handle-crashdump -d "$DUMP_DIR" -e collect-data -c
/etc/abrt/event.collect-data.d/
, making it possible for admin to change when to do data-collecting
by a single edit - changing EVENT=post-create to, say, EVENT=analyze.
Whereas proposal (1) can't do this, and needs even more syntax changes
to make it possible.
That's all from me for now. Your thoughts on this?
As a minimum, indicate which of proposals 1/2/3 looks best
(or "least ugly") to you.
- definitely not 3