Brock Pytlik wrote: > Assuming the client is specifying the exact packages to compare against, > down to timestamps, then I could see this working. If the packages aren't > specified to timestamps, then we haven't really made any meaningful > guarantees about correctness.
True. > 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). 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'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. 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. Danek _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
