1 |
On Saturday, August 29, 2015 2:19:23 PM Rich Freeman wrote: |
2 |
> On Sat, Aug 29, 2015 at 12:35 PM, Fernando Rodriguez |
3 |
> <frodriguez.developer@×××××××.com> wrote: |
4 |
> > It's probably easier to do this: |
5 |
> > |
6 |
> > # cd /usr/portage |
7 |
> > # rm -r * |
8 |
> > # git clone <repo-uri> . |
9 |
> |
10 |
> The only issue with this is that all the files end up being owned by |
11 |
> root. I'd just create /usr/portage, chown portage:portage |
12 |
> /usr/portage, and then let emerge --sync take care of the rest. |
13 |
|
14 |
That is true, I didn't think of that. However, emerge --sync must run as root |
15 |
because that's how I've done it for my local overlay and I just noticed that |
16 |
even my /usr/portage (I'm still using rsync) is owned by root:root with the |
17 |
exception of distfiles which is owned by root:portage. Probably because at one |
18 |
point it got corrupted after syncing and I copied it from a network machine. |
19 |
Fixing it now. |
20 |
|
21 |
> To cut down on replies, I'm not sure what the emerge --sync behavior |
22 |
> is if you have changes in the tree. I suspect that as long as they |
23 |
> don't conflict they'll still sync, but in general you shouldn't leave |
24 |
> uncommitted changes lying around /usr/portage. It is just convenient |
25 |
> to be able to tweak packages, get them cleaned up, and then generate |
26 |
> patches. |
27 |
|
28 |
At least for overlays portage does a git pull. It may pull the changes from |
29 |
the server but it will not even try to merge them (it can't since there's no |
30 |
commit to merge) so it will tell you to either git checkout the file to discard |
31 |
the changes or commit them. Even if you do commit them I believe it will ask |
32 |
you for a merge commit message so it's not something that portage will do |
33 |
automatically. Best to create a testing branch for your changes and checkout |
34 |
the master branch before syncing again. |
35 |
|
36 |
-- |
37 |
Fernando Rodriguez |