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 -
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
