RPM Community Forums

Mailing List Message of <rpm-devel>

Re: modular %posttrans-like scripts

From: Jeff Johnson <n3npq@mac.com>
Date: Wed 27 Aug 2008 - 15:13:18 CEST
Message-id: <73878925-8DC0-4074-94D3-1520953A19EB@mac.com>

On Aug 27, 2008, at 2:57 AM, Alexey Tourbin wrote:

> I need modular and configurable %posttrans-like scripts.
> Examples:
> 1) automatic run of update-menus, if package has /usr/lib/menu/*
> 2) update-desktop-database -- /usr/share/applications/*.desktop
> 3) gtk-update-icon-cache -- /usr/share/icons/hiclolr/*

Need known, the issue of automagic cache management has
come up multiple times on almost every rpm related list over the
past couple years.

My proposal for an implementation was here


Part of the reason for adding dependencies on parent directories
was to establish "owenership" or cache directories so that
a package-contains-directory-content-trigger could be wired up.

The package-contains-directory-trigger script contents then could come
from either a package tag or from an external .../Triggername script.

Generalizations from a /path/to/directory/ (note trailing slash) to
patterns could then be attempted.

> I mean that, for common tasks, I do not want packagers to write
> their %post-like scripts at all.  Simple cache updates should
> be handled by rpm itself.

Here's a contrarian POV:

Should packages start/stop daemons? Restart daemons? Check
for daemons running and undertake other actions?

Should an entire package install transaction be terminated because, say,
some daemon is mis- (or notyet-) configured correctly, and won't (re-) 
What other errors from attempting daemon management need handling by
the package manager? What other package manager state needs to
be adjusted when a daemon mis-behaves?

Caches are no different than daemons. Both are persistent system state
that is imperfectly maintained by a package manager, which runs
at odd times with too narrow an execution context to ever be  
completely and
generally successful.

(aside) My own POV regarding daemon/cache management with packages
is deeply conflicted, do not interpret the above negatively.

But I totally agree that if cache updates are undertaken by packages,  
the implementation should be automated and simplified. It takes years to
get all the package monkeys trained up on what to do if every package  
modifies the cache needs to be modified, and by the time you finish  
some Newer! Better! Bestest! means to accomplish the same goal.

> Now, is there somehting like this in rpm5.org, to start looking at?

There's the Mandriva solution, called "file triggers", to the cache  
problem in lib/filetriggers.c. I dislike several things with the the  
Mandriva implementation, but the idea is closest to being generally  
useful IMHO.

IIRC, SuSE is attempting to use %posttrans, but my memory may be flawed.
Its certainly easy enough to find out what SuSE is doing.

Fedorable likely has Yet Another Approach, but I've forgot what.

Personally, I'd attempt to use the existing trigger code to fire
on package-contains-directory (as parent), collapsing multiple firing
instances into the existing %posttrans execution stage of the state
machine, rather than inventing Yet More Goop in rpm.

73 de Jeff
Received on Wed Aug 27 15:14:26 2008
Driven by Jeff Johnson and the RPM project team.
Hosted by OpenPKG and Ralf S. Engelschall.
Powered by FreeBSD and OpenPKG.