File Triggers (was Re: Proposal (and yes, I'm willing to do stuff!): Must Use More Macros)

[Panu Matilainen]

On Wed, 10 Jun 2009, Nicolas Mailhot wrote:
>
> Le Mer 10 juin 2009 10:59, Florian Festi a écrit :
>>
>> Nicolas Mailhot wrote:
>
>>> 1. something auto-triggered transparently (didn't we learn anything
>>> from
>>> existing package triggers?).
>>
>> I think you make the wrong comparison here (although I admit that the
>> matching names make it tempting). Triggers fill holes in the scriptlet
>> mechanism and though are restricted to obscure and complicated cases.
>
> The new trigger proposal has exactly the same problem as existing
> triggers: processing which is specified in a separate package, and
> happens magically if this package is available (on system or on build
> root), without the packager of the current package having any control
> on it. It will lead to exactly the same weird bugs and packager pain.
>
> Again, if you think you've factored out some cool processing function,
> please oh please give it a proper name/id and convince packagers to
> explicitely invoke this name/id in their specs do not inject code
> behind their backs.
>
> Wishing it all to happen transparently with no packager action is
> laudable, but in practice all past attempts to do so have ended up in
> pain for packagers and as they say the road to hell is paved with good
> intentions

File triggers are certainly not the holy grail of packaging, they're only 
applicaple to a pretty limited set of situations, from the top of my head:

1) Caches updaters which you only want to run once per transaction:
- ldconfig
- scrolkeeper-update
- gtk-update-icon-cache
- update-desktop-database
- fc-cache

2) Files in well-known locations that might be automatically registerable:
- install-info add + remove of %{_infodir}/*.info*
- init scripts (chkconfig --add/--del, service stop/condrestart)
- gconf schema install+remove
- plugin registrations

The cases in 1) are the "classic" file trigger examples, things that 
aren't absolutely critical for the package itself to be runnable, and 
where false positives / multiple unnecessary runs are not dangerous at 
all. They're just telling some other package "please update your caches". 
I dont see any point in requiring special extra magic in specs to activate 
them.

The cases in 2) differ in varying degrees. Info-file 
registration/unregistration seems safe enough to me: by putting an *.info* 
file into %{_infodir} you are announcing it's an info file. There's not 
much room for mistakes here I'd think, and it's quite close to category 1) 
actually, except it needs to run at different times (to handle removal). 
Services and gconf .. might not be so obvious, and whether plugin 
registration/unregistration can reliably be done automatically is
case by case.

In both categories there's a big difference to the current name/provide 
triggers: with file triggers you knowingly place something into some other 
packages directory, so following the principles of directory ownership you 
should already depend on the other package. With name/provide triggers any 
completely unrelated package can do anything at all at any time. Maybe 
packages should only be able to add triggers on directories they actually 
own (subject to abuse too but then what isnt...).

AFAICT, you're talking what would basically be "a named trigger", to which 
packages "subscribe to" if they want to. It's not at odds with file 
triggers at all, and both are likely to get implemented sooner or later. 
What distros choose to use for particular task is up to their packaging 
committees and whatnot, rpm is to only provide a mechanism, not policy 
or any magic internal triggers here.

 	- Panu -