On Fri, 5 Jun 2009, Ray Strode wrote:
Hi,
On Fri, Jun 5, 2009 at 2:05 PM, Adam Williamson<awilliam@xxxxxxxxxx> 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 -
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
