James Carlson <james.d.carlson at sun.com> writes: > I've got a very early webrev that shows what I'm planning to do with > the class action script problem in ON. If anyone has the time, I'd > appreciate comments on either the code or the outline below (which > will eventually find its way into the bugzilla entry). > > http://cr.opensolaris.org/~carlsonj/webrev-268/ > > I've done quite a few greps over the source base looking for other > instances of this problem or ones that could be problematic, but I > haven't found any more. > > I'm currently working on a test harness that'll run some sample > configuration files through the mill. It's not too sophisticated, but > it should give me a good check for regressions. > > The basic design scheme is this: > > - I'm not removing the #ident entries from the class action scripts > themselves; that's part of a bigger gate-wide change. Only the > copyright and CDDL changes where needed.
Our plan was for this to be done as-needed (in the same way as the CDDL header update), in the case of #ident and similar. > - Code that strips the #ident entry from the target of the script > and may update it with a newer version is removed entirely. This > means that upgrading from pre-hg to post-hg (as opposed to a clean > install) will generally leave "#ident" hanging around in the > upgraded configuration files, if it was there before. > > The reason for this choice is that, longer term, #ident just has > no meaning, so there's no good reason to be massaging it on > upgrade, even just for the purpose of removing it from old > systems. It's better that the manipulation logic flees the scene. I think I agree with that, but I don't have to deal with support. Is that the kind of thing likely to confuse a vendor's support people? (it being there but static, as compared to not there at all?) I don't make any judgement as to whether it should be done as you suggest even if it would confuse them. > - Specific per-file notes: > > SUNWdhcsr/preinstall > This is needed for upgrades from S8. I'm reluctant to strip > out that support now, as it's a fairly recent release (in > terms of Updates) and we have no explicit upgrade targets. I had thought the general policy of things was N-2, which in this case would be 9 or 10 to Nevada. (I'm asking mostly because I want to make sure I don't have that entirely wrong in general) > SUNWrmodr/i.master > CR 1183586 upgraded this file to 1.156 in Solaris 2.5. Given > that there's no way we'd support upgrading from 2.4 or earlier > directly to Nevada or newer, it's time to haul this code back > out. > > common_files/i.confupdate > CR 4009768 removed the last reference to this class-action > script 11 years ago, but didn't clean up. Simply remove it. > > common_files/i.pcicconf > The only use of this class was commented out by the fix for CR > 1267303 (11 years ago), and then deleted entirely by the fix > for CR 4185150 (9 years ago). It's time to retire this one. > While I'm there, SUNWpcmci also doesn't use "preserve" at all, > so this can be removed. > > common_files/i.policyconf > No change as the reference is only in a comment. > > common_files/i.publickey > The fix for CR 1094626 fix broke this code pretty thoroughly. > I coded up a new version. (Extensive testing needed on this; > it may be wrong at the moment.) For what it's worth, as my comments in (our) bug state, this breakage will show itself when upgrading to a post CDDL Nevada, I didn't find a bug complaining that it had, but I didn't look too hard. Perhaps there should be one, even if the fix comes in via us? -- Rich
