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 >important. 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. ;o) >#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 well. 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 miraculously notwithstanding). ;o) -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - X.org X11 maintainer - Red Hat
