Quoth Alan Maguire on Wed, Jun 11, 2008 at 10:55:53AM +0100: > Nice summary of the options. Defaulting to ordered > storage/retrieval would be my preference here, with > possible future changes based on explicit requirements > for unordered value support. I'm not quite sure what > constraints the network repository requirements would > impose - what do you think Stephen?
Let's just resolve to add an unordered-property creation interface in the future. > > Is supporting downgrade a hard requirement? > > If we explicitly bumped the version number - and > thus needed to do an explicit downgrade - we could > add logic to bfu etc to remove the value_order column > (this could be done using /lib/svc/bin/sqlite). In testing, > it does seem like earlier configd versions can handle a repository > with the additional value_order column, but it seems > a bit hacky not to register the fact that the repository is > upgraded just to make downgrade easier (adding a minor > version to the schema_version table might be enough though). A minor version seems hygenic, but I don't see a lot of tangible benefit. I think I agree that allowing downgrade is easy enough to just do. > > True. We should be able to assume that the nonpersistent repository is > > in the new format, though, shouldn't we? Unless I suppose we want to > > support changing the svc.configd binary without rebooting. > > Hmm, perhaps the latter scenario may be required for "pkg upgrade" > (though I believe by default it upgrades the inactive BE). Let's just assume that svc.configd is sufficiently critical that it won't be changed without rebooting. If that changes in the future, it should be trivial to fix. David
