On 03/05/12 12:00, Brock Pytlik wrote:
As part of Danek's design for the publication changes, we need a way to
defer dependency resolution until it's known whether a new version of a
package is going to be published or not. I've been struggling with how
to do it for a little while, but I think I've got things nailed down
now. What follows is a rough idea of how I envision the publication
process happening. I've written this as if the processing was being done
on the client side of things, but from step 3 on, it could be happening
on the server side.
1) Do pkgdep generate on all manifests to be published. This step is
unchanged from the present.
2) Do pkgdep resolve -P. -P is a new option which means "postpone
dependency versions." It also eliminates the dependency collapsing and
coalescing which currently happens during the resolve phase.
Dependencies inferred on system packages during this phase will have
versions attached to them, but those inferred on other packages also
being resolved will have versions of "@current."
3) Use pkgsend (in some possibly new form) to fill in file hashes and
possibly pkgmog to apply other transformations so that the all the
actions except for dependency actions, signature actions, and attribute
actions with the name pkg.fmri are what they would be when the package
is finally published. This step may or may not move file data across to
the repo.
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.
5) For each manifest to be published compare all actions except
attributes whose name is pkg.fmri, signature actions (though if the
signing cert is different, might want to mark it as being different
anyway), and dependency actions with the version of the package
immediately less than the version to be published. Put all manifests
with at least one different action in the "different manifests" set. Put
the rest in the "identical manifests" set.
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?
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.
-Shawn
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
