On Wed, 10 Jun 2009, Nicolas Mailhot wrote:
Le Mer 10 juin 2009 13:21, Panu Matilainen a écrit :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-cacheActually, I doubt we will ever run fc-cache once per transaction. The consequences of bad fontconfig caches are just too high. What we've been doing is runing fc-cache just-as-needed by making each srpm install files in a different directory and having resulting rpms refresh only this directory cache, instead of processing all the system font directories each time a font package is installed.
Well, I'm not intimately aware of the font handling details nor do I want to be, I was just under the impression the font cache belongs to the category 1). And this is why the actual script to do whatever magic it needs to do, when it needs to, would be in a distros fontconfig package, not rpm.
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.Multiple runs yes, false positives do not be so sure. False positives is the main weakness of this proposal and "good stuff will happen if the autoselection is correct" is very different from "bad stuff won't happen if the autoselection is false".
False positive in this context would mean either a) the cache update run without needing to b) a package put something into a wrong directorya) is harmless as per multiple runs, b) is a grave packaging bug which with file triggers would be caught when installing the buggy package, instead of next cache update started by something else which then might blow up/issue warnings long time afterwards.
They're just telling some other package "please update your caches".And relying on the cache updating utilities to have ironclad false positive protection logic. Which is not a given, since those utilities have always been explicitely invoked with a human sanity-checking input files before.
See above, they already need an ironclad false positive protection.
BTW: the system can usually manage when those caches are stale, not when they are corrupted.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).This is backwards IMHO 1. it relies on all interesting files having a clear FHS location or unambiguous file name
The idea of file triggers is *based* on the "well known locations". If something doesn't have a clear and well known location, file triggers are not at all the right solution for it.
2. it relies on the packager guessing the right places to put his files to trigger processing. The logic should not be "I have an info file, let's put it here so rpm guesses it's an info file and does the right thing".
There's hardly guessing involved, you put things where they belong just
like you're currently doing: the canonical location for info files is
%{_infodir} and not %{_libdir}/mypackage/ for example, and the info
trigger would not look anywhere outside %{_infodir}. So for the average
autoconf using software it's taken care of by %configure already.
Again, if something doesn't have a well defined place, file triggers
shouldn't be used.
The logic should be "I tell rpm this is an info file and
rpm does the right thing, including installing it in the right place".
That forces *rpm* to know something about any arbitrary file type and location you might ever want to handle. You know how "well" that works for automatic dependency generation - I really doubt you want more of the same. The knowledge belongs to the packages knowing how to handle something, be it fontconfig or icon cache or whatever.
This is of course the POW of a packager that has to cope with imperfect tools that try to be smarter than they can be, not the POW of the person that writes the smart tools and is convinced he can't do wrong.
See above, this is why you dont want *rpm* in control of things, only to provide a mechanism to utilize where it makes sense.
Now, some way to register build-time trigger warnings "your package is installing X file that seems to be Y, please consider processing it with %_zzz y" would be nice. But that's something else entirely.
Well you snipped out the part about "named triggers" which would be something to this direction: an opt-in feature your package claims interest in (or "subscribes", whatever terminology you want to use). A somewhat related thing: it'd probably be a whole lot useful to store the mime types of files in headers than it is to store the exact libmagic strings containing image sizes and whatnot.
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.To put it another way: automatic file triggers are policy. Exporting commands packagers may choose to use (or not) is a mechanism.
A file trigger implements a policy, sure. Implementing the policies is up to the package maintainers of a distribution should they so decide, not something that rpm can or should dictate.
- Panu - -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
