On Sat, 2009-06-06 at 15:47 +0300, Panu Matilainen wrote: > On Sat, 6 Jun 2009, Panu Matilainen wrote: I'm glad to see I'm not the only one who replies to himself :) > > > > 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. > If Fedora is willing to play a guinea pig here, I'm game. FWIW (as the idea grew from mine) I'm not ra-ra for triggers - I'd rather get it right slowly, as you suggest. But I guess it has to get tested _somewhere_... > 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. Yeah, MDV had that problem with file triggers. For 18 months we had to keep "if you're an old version run these macros" junk in the specs. But that's never going to _not_ be the case (unless we introduce the code for triggers, then wait a year or two before using it. Or longer, in the case of packages that are dual purpose for RHEL / EPEL, I guess.) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
