Improve "native" rpm file triggers

[Denis Silakov]

%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.

[Jeff Johnson (n3npq)]

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
incompatibilities.