Richard Lowe writes: > James Carlson <james.d.carlson at sun.com> writes: > > 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.
I'm happy to remove those as well. I just didn't want to do it now in case these bits might need to integrate before the cut-over. > > - 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. I think it's defensible. Despite the work that we put into supporting upgrade, a lot of systems are installed fresh. Given that we're removing the keywords from those files, most systems will likely not have these possibly confusing bits around. For those that do, it's a word of explanation to support. For the same reason that "/usr/ccs/bin/what" will no longer tell you where that binary came from (at least for ON-delivered files), you can't do the visual equivalent on text files and hope for a useful result. I've looked through a fair number of support cases, and I don't see evidence that anyone relies on the #ident lines in the configuration files. (Even if they did, I'd certainly question whether that's a reasonable practice, as there are any number of scenarios in which this information doesn't reflect reality.) > > - 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) That is the general rule, but it's not exactly the only path we take. The number of releases supported for upgrade is a Sun business decision and often takes into account other issues such as third party software support and platform issues. I can't predict right now what they'll decide to support, but I'm fairly certain that we wouldn't want to go backwards in time (e.g., assuming upgrade from S7->S11 is valid when S7->S10 isn't), so the conservative route is to assume S10's list for now. It's possible the logic can go in the future. Yes, I realize this shouldn't really be an OpenSolaris issue, but I'm not sure how to make them line up otherwise. > > 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? I'll search and file a bugster CR if there isn't one already. -- James Carlson, Solaris Networking <james.d.carlson at sun.com> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
