Quoth James Carlson on Mon, May 21, 2007 at 08:33:06PM -0400: > David Bustos writes: > > Quoth James Carlson on Fri, May 18, 2007 at 03:47:52PM -0400: > > > Doing this seems like the simplest and easiest to defend > > > implementation. The problem, of course, is that it's an undocumented > > > interface, and it could be ripped out from under me. I thus need to > > > make it Stable. > > > > I don't recall the particulars of how inetd upgrade works, but can you > > delay the conditional work to after boot? > > 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)? > 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? David
