On 04/18/12 15:54, Danek Duvall wrote:
Brock Pytlik wrote:
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).
I'm trying to recreate what I was thinking at the time, and my best guess
was simply that I misread your initial question.
However, here's a scenario:
- publish FCS package: [email protected]
- publish SRU package: [email protected]
- publish update package: [email protected]
The update package would need to be compared to the FCS package, since the
SRU package represents a divergent branch. I don't think there's any way
to determine that automatically, though, meaning that you need to tell the
publication tools specifically that the FCS versions are the ones you want
to look at.
I'm not sure I agree with that. I would think [email protected] sould be compared
against [email protected], assuming that they're all ending up in the same
repository. To extend the comparison further, I'd also say that 1.2.0
should be compared against 1.1.10 (assuming that had been published by
the time 1.2.0 came along), not 1.1.0 nor 1.0.0. I don't see why you'd
compare against [email protected]. The one reason I could see is that since we
have separate repositories for support/dev/release, we want all package
versions published in release to appear in support. To use the example
above, because we published [email protected] to release, we want [email protected] to
appear in support, even if it's identical to [email protected]. Is that the
thinking behind the example provided?
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.
What would be bad/corrupt/wrong about it? It wouldn't be optimal, I guess,
but it wouldn't be any more incorrect than simply publishing every package
again, differing only in their versions.
Well, imagine that a@2 removed functionality present in a@1, and a@3
restores said functionality. Your generated dependencies will be on a@1,
instead of a@3 so a@2 will satisfy them, but not provide the needed the
functionality.
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.
Yeah, that's what I was talking about. I'm going to be building the IPS
SRU from a fresh workspace that doesn't have a private repo yet, or at
least whose repo is empty. I could populate it with the reference bits
from RE's repo, but if I'm going to go to that trouble, why not bundle up
the work a bit into the command?
That's an excellent idea, but I don't see what the reference surface
buys you here. I can compare against the "immediately less" than package
in the repo once I grab the repo's catalog.
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.
Let's do that. We can add locking later if there's a demonstrated need for
it.
Sounds good to me.
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?
Locking a remote object seems to me to be tricky at best. What if I forget
to unlock it, for instance?
I agree it's not an easy problem to solve, that's one reason I ducked it
in the proposal.
I see how a lock is the only way to have absolute correctness when people
are publishing simultaneously to the same branch of the version space, but
I think that simultaneous publishing is going to be rare, so I'd rather not
have the lock, unless there are other problems it solves.
Sounds good to me. All I've been trying to say is that if we don't have
a lock, we need to be clear about what we do and don't support and we
should communicate those restrictions clearly to users.
Brock
Danek
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
