[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 Fri, 5 Jun 2009, Ray Strode wrote:

Hi,

On Fri, Jun 5, 2009 at 2:05 PM, Adam Williamson<awilliam 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 -


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