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