On 07-08-2011 07:05:03 -0400, Rich Freeman wrote: > 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.
Not sure. You could branch I guess. It takes more work, undoubtedly. > 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. This indeed makes it difficult. > 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). I don't feel users should be playing with these things in general. I see the tree assembling thing more as a technical way to deal with some given legacy and limitations. Admittedly, it isn't perfect, and many people seem to intend doing things with a git-based tree that cannot be done with now CVS, and an assembled tree wouldn't really support it out of the box either. -- Fabian Groffen Gentoo on a different level
