[Fedora-packaging] Re: Suggested ScriptletSnippets (icon cache) changes

[Panu Matilainen]

On Wed, 28 Jan 2009, Rex Dieter wrote:

> Rex Dieter wrote:
>> Bill Nottingham wrote:
>>> Enrico Scholz (enrico.scholz at informatik.tu-chemnitz.de) said:
>
>>>> ?  All relevant Fedora releases should understand %posttrans and this
>>>> speeds up things significantly.
>>> 
>>> As posttrans isn't collated into a single run, it just moves the total
>>> of calls from point A to point B, and therefore would theoretically
>>> only speed things up via cache effects.
>> 
>> posttrans could be a win if the idea from
>> https://bugzilla.redhat.com/show_bug.cgi?id=170335#c33
>> ever came to fruition.
>
> nevermind, recalled that posttrans was previously considered and rejected, 
> since posttrans isn't called on erasure (only install/upgrade).

Yup, %posttrans for erase is kinda hard when the package header(s) that 
the regular rpm scriptlet machinery needs are long gone by the time 
%posttrans runs.

I've been playing around a bit with the "file triggers" concept recently, 
a very crude but lightweight version is actually possible with a 
three-liner patch to rpm 4.6 (heck, even 4.4.2.x) + bit of lua scripting. 
This is nowhere near real-world usable (see below) but in case somebody 
wants to tinker and play around, a quick and dirty example is here: 
http://laiskiainen.org/tmp/rpmhook-example/

This tries to get by with just watching bunch of selected directories and 
launching associated hooks if the directory times change, which is fairly 
close to being enough, at least for many things:

[root at turre rpm-4.6.x]# ./rpm -Uvh --noscripts 
/tmp/gthumb-2.10.10-3.fc10.x86_64.rpm 
/tmp/seahorse-2.24.1-1.fc10.x86_64.rpm
Preparing...                ########################################### 
[100%]
    1:seahorse               ########################################### [ 
50%]
    2:gthumb                 ########################################### 
[100%]
ldconfig hook caught:
   -> /usr/lib64
desktop_db hook caught:
   -> /usr/share/applications
scrollkeeper hook caught:
   -> /usr/share/omf

Icon cache gets missed here as the files go into subdirectories of 
/usr/share/icons/hicolor/, it'd need watching on all the directories 
recursively. This approach will give some false positives too, like gthumb 
putting files into /usr/lib64/gthumb/ triggering ldconfig needlessly, otoh 
in many cases the false positives are harmless as it only runs once.

The nice point about using directory timestamps would be that it avoids 
potentially *very* expensive filename/regex matching on the entire 
transaction set filelist + needing to store the matches somewhere, but 
whether that's sufficient for real-world use I dunno... Also this doesn't 
handle chroot at all, and the hooks should come from the relevant 
packages, not from some central rpm scripts which in turn means the hooks 
should be in headers etc.

 	- Panu -