On Sun, Aug 7, 2011 at 5:12 AM, Fabian Groffen <grob...@gentoo.org> wrote: > On 06-08-2011 20:55:05 +0000, Robin H. Johnson wrote: >> Problems: >> - atomic/well-ordered commits that span packages, eclasses and profiles/ >> directories. (Esp. committing to eclasses and then packages >> afterwards). > > This can be done with a single commit to the rsync tree script, and it > doesn't necessarily need git repos. >
What exactly are you thinking about here. How about this use case: I have a list of 150 packages/versions. I want to make all of them go from ~x86 to x86 at the same time. If they're all in one git repo, then I can use a script or whatever to go through every one at leisure and rekeyword them. Then I can do a repoman scan on the entire repository for an hour or two if I want. When I'm happy I can commit everything atomically. How do you envision doing this by just making a single commit to the rsync tree script if the files are in multiple repos? Right now that rsync tree is pulling in all those files already - in the ~x86 version. Do you propose cloning all the repos, fixing the arch flag in the new repos, and then re-pointing the rsync tree atomically? That would work, but any commits to the 150 packages by others in the meantime would get lost, and it seems a bit painful to do it this way. I can see how you could atomically add or remove 150 packages entirely, but not how you can tweak individual versions of packages without a fair bit of pain. Admittedly, you could have some clever solution in mind that I'm just not grokking. The other thing that was tossed out is having multiple repos, but putting things like kde/gnome in their own bigger repos. I'm not sure this is going to work, since it only works for those particular situations. A package can only be in one repo, so you can't have one repo for kde, and another repo for everything that uses qt, and another for everything that uses pulseaudio, or whatever. Atomic changes to many packages could be required for any number of unforseen reasons. I can see the elegance of allowing the portage tree to be a collage of packages from different sources, but I'm not convinced we really need this. Users can already accomplish this on their end with overlays. It seems like we're just making the portage tree an overlay of its own. I'm not sure what it really buys us. Just using git in the first place already simplifies distributed development. If you took this idea to an extreme you might not have the rsync server assemble the tree at all, but just push out the official list as a "recommended" list of overlays, and let the users put their own trees together (with the ability to override parts of it). Rich
