[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 13:21, Panu Matilainen a écrit :

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

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

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

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 directory

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

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

The cases in 2) differ in varying degrees. Info-file
registration/unregistration seems safe enough to me: by putting an
file into %{_infodir} you are announcing it's an info file. There's
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

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

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

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