Your step 5 compares the intended package version with the one "immediately less" already in the repo. I think this is likely to lead to confusion. I'd originally envisioned -- and would much rather see -- using a client-defined set of package versions as the basis for this comparison. Perhaps we pass a version of entire or some other incorporation on the commandline and have the client figure out what the right set is from there (some heuristics can probably make that reasonably fast in the most common cases), but fundamentally, the client end of the operation needs to define this comparison.
That should get rid of the need to lock the repo. Between knowing in advance what versions to compare against and having a transaction group within which to resolve @current and yea or nay the entire op, I think the repo itself can continue on its merry way during publication (possibly with the exception of removing packages). Danek _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
