David Bustos writes: > Quoth James Carlson on Mon, May 21, 2007 at 08:33:06PM -0400: > > I suspect the answer is "no," because then I need to know what version > > of Solaris I came _from_. If I'm coming from S9 or older, then the > > upgrade works one way (inetd.conf is authoritative about the intended > > state) and if I'm coming from S10 or newer it works another (SMF is > > authoritative). > > Is the thing that's tripping us up here that we can't tell the > difference between a system which was just upgraded to SMF (the > repository contains nothing that inetd.conf says) (in which case we want > to migrate data from inetd.conf to the repository) and one where > inetd.conf has been migrated into the repository, but the user has > undone all of the migration (in which case we don't want to alter the > repository at all)?
Yes, exactly. > > I suppose it's plausible, and (even though I've now put a couple of > > weeks work into setting up various test scenarios; upgrade testing is > > a bear) I can give it a try to see if there's something workable > > there, but I don't see how it's any easier or safer. > > Well it would mean we wouldn't have to commit to the names of the > repository backup links, wouldn't it? Yes, if we're to allow anyone from outside the ON consolidation to pull this trick. The requirement is much lower if we can somehow say that all such problem will forever occur only in ON, and we treat it as a private matter ... but I don't think that's possible. -- James Carlson, Solaris Networking <james.d.carlson at sun.com> Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
