On Tue, 23 Mar 2004, Warren Togami wrote:
#1 need not be limited to anaconda. It could also be a super special
case that apt, yum and up2date handle because it is extremely rare but
That is true, however the anaconda case is the only one I
consider ultra important. Packages often break in ways during
the development cycle that preclude release-to-beta and/or
beta-to-beta, and/or beta-to-release upgrades from working, thus
requiring one time growing pains. While we try to avoid them
whenever we can sanely do so, it is not always _easily_ and
_cleanly_ possible. Different people will debate what "easily"
and "cleanly" mean likely, but I have my own definition.
Before we get into any big long winded and highly opinionated
discussions of the topic however, note that the xfs and
ld.so.conf problems /are/ now solved in xorg-x11 CVS by using
trigger scripts based on the triggers that Barry Nathan posted in
bugzilla. So, all debating aside, the trigger solution has been
chosen and implemented, and will appear in the .8 package build.
#2 triggers MAY not be a bad thing if the implemntation is good, and
unlikely to introduce any security related problem. What specific
concerns do you have about triggers in this case?
I would never disagree with that, however the whole topic of
debate centers heavily around the word you've emphasized above -
"MAY". Yes, a _properly_ written trigger script that has zero
bugs in it, and just works, can be a good solution.
My main points in previous discussions about using triggers to
solve problems are that:
- Trigger scripts have at times been used by some people when
they were not necessary for the given problem they were trying
to solve. In some of the cases I have seen, a trigger was used
when a "pre/post/preun/postun" script should have been used,
and it appeared that the person who made the change either did
so in a hurry without much thought, or perhaps they just
misunderstood triggers and rpm scripts and which should be used
when. It is a rather complex topic unless you've got a lot of
experience writing such rpm scriptlets.
- Trigger scripts, like any other code, can easily have
mistakes/typos, flawed logic, or some other errors in them when
they're created which the author and any others who review them
may not notice right away. I have done this myself a few
times, and I've seen various Red Hat packages as well as 3rd
party packages have broken trigger scripts added to them as
I believe in the majority of cases, it was never developer
carelessness, but rather it was just the simple fact that human
error happens. The difference with normal code, is that you can
fix normal code in the next release and be done with it.
With triggers however, if a bug occurs, it is not usually spotted
right away, and if the packages get deployed and used, the broken
trigger is sitting there and _will_ execute. Even if you find
the problem after the fact, and fix the trigger script in a
future rpm package release, the trigger script that is already
installed on a person's system is what will be executed, not the
new bugfixed version.
So in summary, the concerns I have about triggers, is that while
a "good properly written bug free" trigger is a mighty fine
solution, while I do not have numerical statistics to back this
up - the majority of trigger scripts I've seen added to packages
are rarely bug free the first time around, and when the bugs get
found, depending on the extent of the damage, they're a huge pain
to deal with, and users just keep reporting bugs again and again
and again, long after the bug was long since fixed.
Don't take my word for it though, add triggers to all your
packages just for fun, and witness the joy first hand. ;o)
As such, when a problem arises, which could potentially be fixed
by a trigger, I prefer to try to find an alternate solution if it
is at all possible, because triggers are evil, statistically
speaking (well written triggers that got it right the first time
Mike A. Harris ftp://people.redhat.com/mharris
OS Systems Engineer - X.org X11 maintainer - Red Hat