Quoth James Carlson on Mon, May 21, 2007 at 09:05:54PM -0400: > David Bustos writes: > > 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.
Ok, then this is a systemic problem in the current repository that we aim to address with the enhanced profiles project. With the customizations separate from the defaults, we should be able to tell whether the inetd.conf-prescribed services have been migrated into the repository, even if the user has "customized" them by deleting them. So I think you should target your solution at a post-enhanced profiles repository, and then look for a sufficiently-reasonable-for-least-work stopgap until then. Say by having inetd-upgrade only migrate inetd.conf when no migrated services are detected? Then only the user who undoes all of the migrations is injured, which seems pretty extreme anyway. > > > 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. Well I believe the prevailing winds of configuration manipulation (migration and upgrade) are that it's better for everyone involved to do the work after boot rather than before. That should ease most problems since the full functionality of SCF should be available. As such I think we should avoid investing in upgrade-time configuration manipulation (a position partly forced by insufficient unbooted- repository functionality), which unfortunately prompts developers to scrounge for post-boot hooks since neither SMF nor the packaging system offer solutions for the common cases. You, on the other hand, have it better than most, in inetd-upgrade. David
