[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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

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
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

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 -

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]