File Triggers (was Re: Proposal (and yes, I'm willing to do stuff!): Must Use More Macros)

[Panu Matilainen]

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 -