Improve "native" rpm file triggers
Bug #911717 reported by
Denis Silakov
This bug affects 1 person
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| RPM |
Confirmed
|
Medium
|
Unassigned | ||
Bug Description
%trigger currently lacks two features for it to completely replace the legacy mandriva implementation:
1) Regexp matching - %trigger currently does matching on wildcards and directories only.
2) Passing of matched results to trigger script - the legacy Mandriva file triggers passes all matches as arguments fed through STDIN, while firing trigger just once. %trigger OTOH lacks a way to pass the matched files/directories, while the designed mechanism is to fire once per item matching an expression. For Mandriva Linux 2011 a hack was added to prevent firing file triggers multiple times.
Revision history for this message
| Jeff Johnson (n3npq) wrote | #1 |
| Changed in rpm: | |
| status: | New → Confirmed |
To post a comment you must log in.
Yes: %triggers use glob's not *RE's to match paths. Its
unclear what benefit there is to use *RE's but it isn't
hard to permit *RE's insead because of what is known
as a "mire" obect: basically a container that is used
for all "pattern matching", so the actual implementation
is no harder than changing a manifest constant in
the object constructor.
The harder question is one of design:
SHould *RE expressions against paths be permitted?
because (I believe) most packagers have little understanding
of either glob or *RE expressions, all they know is that "*"
matches anything/
Passing a tuple of matches is needed only if Mandriva lfile trigger ogic
is to be re-implemented. Its certainly expedient to be able to
achieve parity between two file trigger implementations. Passing
in a tuple from a match is no harder than creating a conventional
macro name that is created/destroyed around the script let execution
(which is already macro expanded before being executed).
There are harder/deeper issues than expanding a template to fill
in some tuple variable with values because of the need to support
embedded interpreters: i.e. the expansion that "works" for shell
isn't going to work for lua/perl/
But this is mostly establishing equivalent conventions for in-line
expansion in each interpreter dialect.
Note that argv analogues are possible but $1/$2 are already in use
with triggers, and there are proposals to add a $3/$4 related to
"multilib:" that have been proposed. so an in-line, per-interpreter,
template convention is the easiest way to avoid some tedious
incompatibilities.