David Bustos wrote: > Quoth Liane Praza on Tue, Jan 08, 2008 at 11:12:23AM -0800: >> Let's just make it "refresh" and make it public. For convenience, in >> the non-SVCCFG_REPOSITORY case, it'll call svcadm refresh. Otherwise, >> it'll use your original code. The detection you wrote for failure will >> now be used for good instead of evil. ;) >> >> The reasons for making it public: >> - it won't be harmful if people have called it even once we have early >> manifest import, >> - potentially i.manifest/r.manifest might be improved using it, and >> - most importantly, it allows the "boot net/cdrom" repair scenario >> to do service refreshes. > > Doesn't this command imply the need to tell when refresh is necessary, > and what changes it will make?
hmmm. Suggests it'd be nice, sure, and as I suspect you've seen I've been updating related bugs. But, I think it's separable and valuable even without the work of determining what's been modified in the existing svccfg session. > What stability level? I would like to replace it with transactional > semantics (i.e., a "commit" subcommand) in the profiles project. Committed. And Patch binding. I suspect we'll want to backport the offline refresh functionality, and don't suspect we'll be backporting profiles. If profiles come in before Nevada ships with a better solution (or new subcommand) for the offline repository problem, and we determine it's better to obsolete this in favor of the new interface, that's relatively simple. (Modulo a hypothesized but not guaranteed backport.) liane
