[Rpm-maint] discussion on problems of RPM in real life packaging

[Stanislav Brabec]

Pixel wrote:
> Stanislav Brabec <sbrabec at suse.cz> writes:
> 
> > Particular problems there may have different severity and different
> > complexity. The worst one seems to be Problems of Scriptlets / Database
> > rebuild.
> 
> mandriva is currently experimenting something on this subject:
> 
> http://wiki.mandriva.com/en/Rpm_filetriggers
> 
> implementation is quite rough and simple:
> http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/rpm/current/SOURCES/rpm-4.4.2.3-filetriggers.patch?view=log

Mandriva patch defines patterns evaluated by RPM runtime.
+ simple global adding of new directories
+ simple global adding of new scripts (e. g. gtk-update-icon-cache for
  KDE apps, if GTK+ is installed).
- needs pattern evaluation in runtime
- to enable this feature, adding a line to spec is required
  (implementation problem only)
* no, install-info is not a good candidate fot this technique,
  see http://wiki.rpm.org/Problems_of_Scriptlets (this is an
  implementation of "Database rebuild", install info needs "Registry,
  which needs subscription and unsubscription".

My idea of function is very similar, but idea of implementation was
different: Adding a dedicated virtual symbol created by autoreq/prov
scripts and triggering these scripts by this symbol.
- adding new directory means rebuild (not a big problem)
- impossible to assign new script to existing package
+ no pattern evaluation in runtime

Summary: Mandriva solution looks a bit more powerful.

>From implementation level of Mandriva patch:
- Regexp evaluation is a bit expensive. In real, we need only:
  - list of directories to be inspected
  - list of (glob-style) patterns initiating the trigger
  - information, whether triggering should occur in sub-directories
- File queue looks ugly. The best place to evaluate triggers would be
  writing to rpmdb.
- And finally, application, which provides a new trigger script, should
  trigger its initial run.
- Trigger script should have removal procedure defined.


Third idea mentioned in the thread was an uniq call on scripts. To
achieve the same, it proposes a completely different technique:
+ (Maybe) simple to implement.
- Packagers still need to write scriptlets manually (including
  cross-desktop scriptlets, e. g. gtk-update-icon-cache for koffice to
  render correctly in GNOME menu).
- In worst case, complexity n^2
- Fragile (needs exact string match in scriptlets)


Summary: I would like to propose to accept
rpm-4.4.2.3-filetriggers.patch as an intermediate solution enabling
%_filetriggers_dir by default. We will collect packaging experiences.

Later, when more clean (and more invasive) patch appear, adopting it
would not be expensive. In worst case, it would require trigger
conditionals rewrite.

Triggers on virtual symbols may appear as well, but they are not ideal
for implementing of general one time triggers.

-- 
Best Regards / S pozdravem,

Stanislav Brabec
software developer
---------------------------------------------------------------------
SUSE LINUX, s. r. o.                          e-mail: sbrabec at suse.cz
Lihovarská 1060/12           tel: +420 284 028 966, +49 911 740538747
190 00 Praha 9                                  fax: +420 284 028 951
Czech Republic                                    http://www.suse.cz/