On Sat, 6 Jun 2009, Adam Williamson wrote:
On Sat, 2009-06-06 at 15:47 +0300, Panu Matilainen wrote:
On Sat, 6 Jun 2009, Panu Matilainen wrote:
I'm glad to see I'm not the only one who replies to himself :)
Heh :)
Also for ultimate power the file triggers need to be in headers so that all
triggers are ready for action before the transaction starts, to avoid
unnecessary dependencies and ordering issues. And then you'll need semantics
for upgrade of a package containing file triggers - you probably dont want
the trigger from both the already installed package and the upgraded package
to run.
If Fedora is willing to play a guinea pig here, I'm game.
FWIW (as the idea grew from mine) I'm not ra-ra for triggers - I'd
rather get it right slowly, as you suggest. But I guess it has to get
tested _somewhere_...
Yup. And I think being able to test in a real distro would expose all the
strange cases I haven't even thought of yet much faster than just trying
to puzzle it all together on paper.
Of course there are transition issues... packages relying on file-trigger
behavior wouldn't install correctly on older rpm's not providing the
functionality. This would affect pretty much any mock builds, including
Koji builders... so either the use of file-triggers should be limited to
things that aren't strictly required so this doesn't really matter (most
of the cache updating stuff etc falls to this category luckily) and/or the
file trigger stuff is run-time conditionalized in specs, eg
%post
if [ -z "$RPM_HAVE_FILETRIGGERS" ]; then
scrollkeeper-update
gtk-update-icon-cache
fi
...so initially we'd have *more* junk in specs.
Yeah, MDV had that problem with file triggers. For 18 months we had to
keep "if you're an old version run these macros" junk in the specs. But
that's never going to _not_ be the case (unless we introduce the code
for triggers, then wait a year or two before using it. Or longer, in the
case of packages that are dual purpose for RHEL / EPEL, I guess.)
Btw your initial suggestion of collecting the common stuff into macros
and converting packages to use them would be useful on several ways:
a) Finding out the things that *are* common among lots of packages. While
numerous cases are well and widely known already, I suspect there might
be some that are only specific groups know about (possibly eg java
related packages, I dunno).
b) Making the usages of the common patterns easy to spot by grepping.
c) The transition period cruft can be hidden inside the common macros
without polluting every spec with it.
- Panu -
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
