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 -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
