On Saturday, August 29, 2015 2:19:23 PM Rich Freeman wrote:
> On Sat, Aug 29, 2015 at 12:35 PM, Fernando Rodriguez
> <frodriguez.develo...@outlook.com> wrote:
> > It's probably easier to do this:
> >
> > # cd /usr/portage
> > # rm -r *
> > # git clone <repo-uri> .
> 
> The only issue with this is that all the files end up being owned by
> root.  I'd just create /usr/portage, chown portage:portage
> /usr/portage, and then let emerge --sync take care of the rest.

That is true, I didn't think of that. However, emerge --sync must run as root 
because that's how I've done it for my local overlay and I just noticed that 
even my /usr/portage (I'm still using rsync) is owned by root:root with the 
exception of distfiles which is owned by root:portage. Probably because at one 
point it got corrupted after syncing and I copied it from a network machine. 
Fixing it now.

> To cut down on replies, I'm not sure what the emerge --sync behavior
> is if you have changes in the tree.  I suspect that as long as they
> don't conflict they'll still sync, but in general you shouldn't leave
> uncommitted changes lying around /usr/portage.  It is just convenient
> to be able to tweak packages, get them cleaned up, and then generate
> patches.

At least for overlays portage does a git pull. It may pull the changes from 
the server but it will not even try to merge them (it can't since there's no 
commit to merge) so it will tell you to either git checkout the file to discard 
the changes or commit them. Even if you do commit them I believe it will ask 
you for a merge commit message so it's not something that portage will do 
automatically. Best to create a testing branch for your changes and checkout 
the master branch before syncing again.

-- 
Fernando Rodriguez

Reply via email to