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

Panu Matilainen pmatilai at laiskiainen.org
Sat Jun 6 10:01:08 UTC 2009


On Fri, 5 Jun 2009, Ray Strode wrote:

> Hi,
>
> On Fri, Jun 5, 2009 at 2:05 PM, Adam Williamson<awilliam at redhat.com> wrote:
>> On Fri, 2009-06-05 at 13:50 -0400, Ray Strode wrote:
>>
>>>> It seems to me it'd make sense to convert all these kinds of snippets
>>>> into macros. Am I right, or is there a reason against doing this?
>>> It would be awesome to get rid of the boilerplate.  Honestly though,
>>> I'd rather the solution was "just works" than "replace giant glob of
>>> muck with %{glob_of_muck}"
>>
>> Yes indeed, this would be best in many cases. Some can't really be done
>> like that, though - like the snippets for Tcl and Python to define the
>> version, directories for certain types of file and so on. They're
>> just...informational. Defining them as macros seems the optimal
>> solution.
> Right, totally agree.

Yes, having each and every spec carry the %{!?foo:¤%&¤%} macro goo makes 
no sense at all.

>
>>> For instance, if a file gets dropped under /usr/share/icons/something
>>> rpm should run gtk-update-icon-cache /usr/share/icons/something
>>> automatically.
>>>
>>> the gtk2 package should be able to drop a file in /usr/lib/rpm/redhat
>>> that makes that happen.  likewise, desktop-file-utils should be able
>>> to drop a file there to make update-desktop-database get run and so
>>> on.
>>>
>>> I don't know how hard it would be to fix rpm to allow for that though.

The hardest part is getting the design right the first time, there's no 
changing an "api" that is exposed to packages.

>> This is definitely possible; Mandriva (I know I talk about MDV a lot,
>> I'm sorry, it's what I know! :>) does this, via an implementation called
>> 'file triggers'. This is not yet upstream, though.
>>
>> The MDV patch that implements this is:
>>
>> http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/rpm/current/SOURCES/rpm-4.6.0-rc1-filetriggers.patch?view=markup
>>
>> MDV's wiki discussion of it is here:
>>
>> http://wiki.mandriva.com/en/Rpm_filetriggers
>>
>> It appears to be something upstream has thought about several times.
>> Here's an RPM 5 community discussion of it, with Jeff Johnson's
>> thoughts:
>>
>> http://rpm5.org/community/rpm-devel/2959.html
>>
>> Here's a discussion from the rpm.org Wiki:
>>
>> http://www.rpm.org/wiki/Problems/Scriptlets
> Oh neat!
>
>> I'm not sure what the current status is for rpm.org - whether they're
>> actively working on a solution for this side of things or what.
> Panu, does this patch make sense?

I'm quite well aware of the Mandriva filetriggers patch, but I (too) have 
some reservations about the implementation. Other issues aside, 
constraining file triggers to "stuff that runs after the transaction 
completed" limits the possibilities a lot. Many things need unregistering 
(services, gconf schemas, info files...) and that needs to happen *before* 
the files got removed. That's not possible in post-transaction stage.

I've been playing with a different approach: putting an existing (since 
rpm 4.4.0 IIRC) but completely unused "hook" mechanism into use, this 
allows pushing pretty much the entire mechanism out of rpm proper and into 
Lua, which allows for far more flexibility for distros to customize etc.

The most simple variant consists of a whopping two-line patch to rpm: 
http://laiskiainen.org/tmp/rpmhook-example/
This works by comparing modification times of directories of interest - 
not sufficient for a real-world implementation but still works quite well 
(and with essentially zero overhead) for the "update some cache on demand" 
class of cases, as false positives dont generally matter there.

Things like automatically registering and unregistering info/gconf etc 
files need more information than just "directory changed". What they need 
is access to package file lists and the file "fate" information (such as 
"these files are about to be removed"), and the ability to run the 
"triggers" at start/in middle of transaction. Mostly a matter of planting 
some extra hooks into strategic spots, and extending the rpm-lua 
interface.

One of the nice things about the hook-based approach is that it permits 
each trigger to use whatever mechanism is best suited for the job: 
processing file names/globs and remembering matches can be quite 
expensive, so a trigger that doesn't need the details can just use a 
simple directory modification time based approach.

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.

It's a fair-sized puzzle to get all the bits sufficiently right the first 
time, or alternatively expose things little by little in a manner that 
doesn't paint us in a corner.

 	- Panu -




More information about the fedora-devel-list mailing list