On 03/20/12 10:27, Danek Duvall wrote:
Brock Pytlik wrote:
[snip]
I'm not a fan of this approach because I think it imposes more work on the
user, which means it's more prone to have something unexpected happen.
Perhaps I'm missing something, but if a@1 and a@2 are in the repo currently,
when would a user ever want to compare against a@1 instead of a@2 when
publishing a@3?
It's probably not strictly necessary, but to be fair, allowing it was part
of your proposal, too. The scenarios I see this being useful for are
backpublishing and the branching of the versioning space (maintaining both
the SRU and the development packages in a single repo, for instance).
I'm not sure how it was part of my proposal. I think my proposal
would've compared [email protected] with a@1, but I'm not sure how a@3 could ever be
compared with a@1 when a@2 exists (barring race conditions).
You could also get rid of the lock by grabbing a snapshot at the beginning
of the operation -- simply retrieving the catalog should be sufficient --
in order to get a surface that won't change during the course of the
publication. It'd be nice to be able to freeze that surface over the
course of multiple publications, though. Say I'm repeatedly building and
publishing a component as I'm tweaking its build and packaging. I'm going
to want a fixed reference that doesn't change as I pile my test
publications into the reference repo (or if I'm using the official repo,
find that a new build parachuted in while I was doing my work).
I don't see how grabbing a snapshot would remove the need for a lock.
Sure, I can keep comparing a@3 against a@1 like it was when I took my
snapshot, but if a@2 is in the repo when I go to publish, then I'm still
comparing against the wrong thing. Most importantly, I could decide not
to publish a@3 since it was identical to a@1 and end up with a
bad/corrupt/wrong repo because a@2 was actually present.
I also don't understand the example above. If you're repeatedly building
and publishing a component you're working on, presumably you're not
doing this into the repo that RE's going to be publishing to. I'd assume
that you're doing it into your own private repo. The reference is always
fixed, it's the repo you're publishing to. There's no way to use "the
official repo", whatever that means, at least in my scheme. If you're
publishing to repo X, you're only comparing against packages in repo X.
Now, if what you're suggesting is that you're publishing into your
private repo, but you only want to publish packages that have changed
compared to a reference repo (say the ipkg repo), that's doable, but's
orthogonal to what I've been discussing so far. In that situation, I'm
still not certain what the reference surface buys you but I'll have to
think some more since the reference repo concept wasn't in my design at all.
I'm a bit uncertain as to what "immediately less" means in a branching
version space. If you can define that rigorously, great; otherwise, we can
probably simplify to "compare against tip" and simply require that the user
start off with a repo whose package surface defined by the newest revisions
of each package is the surface they want.
Here was how I implemented "immediately less" in my prototype:
1) Use the name of the package as a pattern for catalog.gen_packages
2) catalog.gen_packages always returns results in descending version order
3) iterate through the results from catalog.gen_packages, if the result
is the first result that the package to be published is a successor to,
then that result is the version that's "immediately less"
It's unclear to me why branching versions matter here. A concrete
example of the situation you're concerned about would probably help me
see the problem better.
I still think that using an incorporation as a reference to a surface makes
sense (at least when considering entire) -- just take the newest packages
that satisfy that incorporation, and stash that list of package versions
until you decide to change them.
Sure we can do that, but I'm not really seeing a reason to do it, at
least it doesn't remove the need for a lock.
As I said when I started this, I'm fine with saying that we don't need a
lock because we're just telling people:
"Hey, don't be idiots. Don't have two or more people publishing
overlapping sets of package names, especially in an adversarial fashion."
I think that's a fine convention to establish.
However, if we don't want to depend upon that external convention, and
we care that the repo is consistent/correct immediately after your
publication finishes, then we need a lock (or a check/abort step).
As far as I can see, stashing the list of package versions aside only
increases the likelihood of ending up with an inconsistent repo, and
doesn't actually produce any benefit. (I should say, it doesn't produce
any correctness benefit I can see. It could potentially give speed
benefits.) What problem is that bit trying to solve?
Brock
Danek
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
