Re: [gentoo-dev] [RFC] gentoo-x86 migration to repo-per-package

[Rich Freeman]

On Sun, Aug 7, 2011 at 5:12 AM, Fabian Groffen <grobian@g.o> 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