Improve "native" rpm file triggers

Bug #911717 reported by Denis Silakov
This bug affects 1 person
Affects Status Importance Assigned to Milestone

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.

Tags: mandriva
Revision history for this message
Jeff Johnson (n3npq) wrote :

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/everything.

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/python/javascript/ruby/tcl etc.

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

Jeff Johnson (n3npq)
Changed in rpm:
status: New → Confirmed
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.