[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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

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

if [ -z "$RPM_HAVE_FILETRIGGERS" ]; then

...so initially we'd have *more* junk in specs.

	- Panu -

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]