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

Panu Matilainen pmatilai at laiskiainen.org
Sun Jun 7 09:31:41 UTC 2009


On Sat, 6 Jun 2009, Adam Williamson wrote:

> 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 :)

Heh :)

>>> 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_...

Yup. And I think being able to test in a real distro would expose all the 
strange cases I haven't even thought of yet much faster than just trying 
to puzzle it all together on paper.

>> 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.)

Btw your initial suggestion of collecting the common stuff into macros 
and converting packages to use them would be useful on several ways:
a) Finding out the things that *are* common among lots of packages. While
    numerous cases are well and widely known already, I suspect there might
    be some that are only specific groups know about (possibly eg java
    related packages, I dunno).
b) Making the usages of the common patterns easy to spot by grepping.
c) The transition period cruft can be hidden inside the common macros
    without polluting every spec with it.

 	- Panu -




More information about the fedora-devel-list mailing list