On 03/08/12 09:25, Shawn Walker wrote:
On 03/05/12 12:00, Brock Pytlik wrote:
[snip]
4) Grab the repo lock. I'm being deliberately vague here. Since we're
comparing the manifest we're considering publishing with one in the
repository, if another package got published after we compared, but
before we published, we might make incorrect decisions about whether to
publish a package. This could be as simple as a convention of not
allowing multiple people to publish to the same repository at the same
time. It could be accomplished by comparing the catalog at comparison
time with the catalog when the packages are being published to ensure
the state of the world is what's expected. It could be an actual lock on
publishing to the repository.
Any physical repository lock implies that this isn't suitable for http
publication. If http publication needs to be supported, there needs
to be a 'pkgrepo unlock' or the like.
Yep, see the last step. As a side note, this isn't really part of
@current. As far as I can tell, is something that falls out of the new
publication model that Danek sent out. That's why I was intentionally vague.
[snip]
6) For all depend actions in manifests to be published which use
<pkg-name>@current in the target or predicate, if <pkg-name> is in the
set of "different manifests", replace @current with the version of the
package in the package to be published, otherwise replace @current with
the version of the previously published manifest
How will you deal with timestamps which are server side, or is your
assumption that @current doesn't include the timestamp?
@current is literally the magical string "@current", there is no timestamp.
7) Now that all dependencies have fixed versions, collapse and coalesce
the dependencies for all the packages to be published.
8) For each manifest to be published, compare all actions except
attributes whose name is pkg.fmri and signature actions with the version
of the package immediately less than the version to be published. Put
all manifests which are different in the "actually to be published" set.
9) Publish each manifest in the "actually to be published" set.
10) Release the repo lock.
I believe this approach will work. Please let me know if you see any
issues with the proposal.
For me, the prototype will likely be easier to follow. This isn't a
failing of yours, it's just hard to visualize the entire process in my
head from text.
Ok, that's why I sent out a draft implementation that handles step 2,
and I'll probably send out another one later which handles steps 5
through 7 or 8.
Brock
-Shawn
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
