On Wed, 16 Apr 2008, Pixel wrote:
Panu Matilainen <[EMAIL PROTECTED]> writes:
[...]
The ldconfig hackery in rpm is going away sooner or later, what I want to see
is some more generic mechanism for packages to queue actions to happen at end
of the transaction. Things like gtk-update-icon-cache only need running once,
so packages just need a way to flag "please run <foo> for me before heading
home." and for these, rpm would only run each unique command once after the
transaction is finished (%posttrans and all).
what about running "uniq" on each all %posttrans scripts? that way
it's easy to avoid duplication.
Something like that, but forget about %posttrans as it is today, it
doesn't really fit the purpose. For one, it doesn't run on erasure.
only pb i see is currently one can't have more than one %posttrans,
whereas running "uniq" would need nicely precise %posttrans like:
%posttrans -p /bin/foo
%posttrans -p /bin/bar
instead of
%posttrans
/bin/foo
/bin/bar
Something I spotted at LWN, probably only because the recent controversy
around it: the new "triggers" feature in DPKG appears to be exactly the
same thing we're talking about here:
https://wiki.ubuntu.com/DpkgTriggers
http://lists.debian.org/debian-devel/2008/03/msg00931.html
I've yet to read the full specification
(http://lists.debian.org/debian-dpkg/2007/04/msg00076.html) but I
certainly will have a look at it to see if (some of) the design is
applicable for RPM, and at least it'll probably give some ideas.
- Panu -
_______________________________________________
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
https://lists.rpm.org/mailman/listinfo/rpm-maint
