On Sat, 6 Jun 2009, Panu Matilainen wrote:
Also for ultimate power the file triggers need to be in headers so that all
triggers are ready for action before the transaction starts, to avoid
unnecessary dependencies and ordering issues. And then you'll need semantics
for upgrade of a package containing file triggers - you probably dont want
the trigger from both the already installed package and the upgraded package
to run.
That said, there are some options that would allow introducing file
triggers without actually putting them to headers. The biggest problem is
initial install to an empty chroot, but it's possible to work around it to
some extent. Keeping the trigger scripts initially more or less internal
to rpm would give the much needed room for experimenting. Once the "api"
details seem about right, the trigger scripts can be pushed to the
"owning" packages where they belong. The other packages relying on
file triggers wouldn't see a thing of all this, except for the initial
leap of faith "rpm will arrange this somehow".
If Fedora is willing to play a guinea pig here, I'm game.
Of course there are transition issues... packages relying on file-trigger
behavior wouldn't install correctly on older rpm's not providing the
functionality. This would affect pretty much any mock builds, including
Koji builders... so either the use of file-triggers should be limited to
things that aren't strictly required so this doesn't really matter (most
of the cache updating stuff etc falls to this category luckily) and/or the
file trigger stuff is run-time conditionalized in specs, eg
%post
if [ -z "$RPM_HAVE_FILETRIGGERS" ]; then
scrollkeeper-update
gtk-update-icon-cache
fi
...so initially we'd have *more* junk in specs.
- Panu -
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
