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

[Nicolas Mailhot]

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.

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

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

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

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.

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.

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

-- 
Nicolas Mailhot