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

[Nicolas Mailhot]

Le Mer 10 juin 2009 15:29, Panu Matilainen a écrit :
>
> On Wed, 10 Jun 2009, Nicolas Mailhot wrote:
> 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.

This is totally orthogonal to invoking this script via file triggers
or not.

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

What will happen is the very same spec will go bang in one build
environment and not another, and people will waste time trying to find
out what's different because of the transparent magic processing. That
happened many times in the past with the redhat rpm customization that
changes rpm behaviour transparently without packager intervention.

> instead of next cache update started by something else which then
> might blow up/issue warnings long time afterwards.

Cache updates triggered by apps are checked upstream. Cache updates
triggered by magic rpm transparent rules only happen in a distro
environment that uses them. I very much doubt there will ever be a
100% match between the regexps file triggers use to identify files and
the rules cache utilities use to identify what to process.

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

That does not force rpm to know anything more than in your proposal.

'Telling rpm X is an info file' can be done via the explicit
invocation of %_frob_info_file X, all rpm has to provide is a way for
people interested in info files to declare a %_frob_info_file which is
then available to other packages (that may use it or not depending on
preferences, distro policies and special cases *they* know of).

*this* is what is missing today. Packagers know what's in their
packages (it's *their* responsability). People know how to write bits
of processing appropriate for X or Y content (this is what SIGs and
FPC do all the time). People in group 2 know how to communicate with
group 1

What's is broken is group 2 can not give group 1 prepackaged routines
to use, because rpm does not allow injecting code that spans multiple
sections (deps, build, install, post, pre, check etc), and that
concern the same subpackage. And thus people have to cut and paste.
You can not tell packagers :
"To add the font file X.ttf, to your subpackage Y, declare:"

%files Y
%do_what's_appropriate_for_fonts X.ttf

and you're done

You have to paste code in build, install, post, preun, etc because of
this (and hope you never mess up with the subpackage identifier all
those sections expect). Which is a huge PITA and impedance mismatch.
The actual file type identification is *not* a problem. It's *less*
work than reading the FHS and putting files manually in a place rpm
would recognize. And in fact the FHS is not that accurate and for a
lot of files location will depend on distro policy, so reading the FHS
is not enough anyway.

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

The processing knowledge does not belong in the package itself. The
file identification knowledge is 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).

opt-in in IMHO safer and saner. And more flexible.

-- 
Nicolas Mailhot