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. > >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. > 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? > 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. > 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 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. Danek _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
