| 1 |
On Sun, Jul 30, 2017 at 9:36 AM, John Covici <covici@××××××××××.com> wrote: |
| 2 |
> On Sun, 30 Jul 2017 09:07:03 -0400, |
| 3 |
> Rich Freeman wrote: |
| 4 |
>> |
| 5 |
>> On Sat, Jul 29, 2017 at 10:58 PM, John Covici <covici@××××××××××.com> wrote: |
| 6 |
>> > |
| 7 |
>> > Well, clone-depth = 0 gave me a syntax error |
| 8 |
>> |
| 9 |
>> Can you provide the entire contents of your repos.conf, and the error |
| 10 |
>> it gives you? |
| 11 |
>> |
| 12 |
>> I wouldn't use a manual checkout for /usr/portage. You can of course |
| 13 |
>> do a checkout elsewhere but your permissions will probably get messed |
| 14 |
>> up if you checkout /usr/portage by hand. |
| 15 |
> |
| 16 |
> Well, I don't have the error message anymore and I did what I thought |
| 17 |
> you suggested -- beffore I got your last message -- I just did a git |
| 18 |
> clone of the repository to /usr/portage and the only unusual thing was |
| 19 |
> the first time I ran portage, it did its global updates and it seems |
| 20 |
> to be working. |
| 21 |
> |
| 22 |
|
| 23 |
Well, if your repos.conf still says to use rsync then you can't use |
| 24 |
clone-depth in it, since that doesn't work with rsync. It might also |
| 25 |
mean that you now have files owned by root in /usr/portage which an |
| 26 |
emerge --sync is going to have trouble dealing with, since it runs |
| 27 |
with reduced permissions. It isn't a big deal - just get repos.conf |
| 28 |
the way you want it (either with git or rsync), delete /usr/portage, |
| 29 |
and let an emerge --sync re-create it. |
| 30 |
|
| 31 |
If you want to do a git clone I'd do it someplace other than /usr/portage. |
| 32 |
|
| 33 |
You really have a few options here: |
| 34 |
|
| 35 |
1. If you look at history all the time just set up /usr/portage to be |
| 36 |
a git repository with clone-depth=0. Make sure you use the repository |
| 37 |
I linked which has metadata pre-generated - if you sync from the |
| 38 |
official Gentoo repo you'll have to rebuild the metadata all the time. |
| 39 |
Plus the mirror I linked also has QA checks so that when a developer |
| 40 |
breaks something it just won't update until somebody fixes it, which |
| 41 |
will save you some grief (maybe 1-2x a year it ends up being a few |
| 42 |
days stale). |
| 43 |
|
| 44 |
2. If you almost never look at history and you care about disk space |
| 45 |
then either use rsync or sync with clone-depth=1 to minimize the size |
| 46 |
of /usr/portage, and then do a temporary git clone when you really |
| 47 |
need it, or browse history online. |
| 48 |
|
| 49 |
Personally I do #1. I have full history, and it syncs a lot faster |
| 50 |
than rsync. Git is smarter about syncing since it knows about history |
| 51 |
and thus what has changed. However, it has to send all the commits |
| 52 |
in-between your current and target state. If you only sync once a |
| 53 |
month it might be faster to use rsync, since rsync only sends the |
| 54 |
final version, and not every intermediate one, so files that were both |
| 55 |
added and removed in the interim don't get sent. However, rsync |
| 56 |
doesn't know anything about history and has to scan the entire tree to |
| 57 |
figure out what has changed. |
| 58 |
|
| 59 |
Oh, if /usr/portage is a git repository refrain from editing anything |
| 60 |
in it unless you know what you're doing. With rsync portage will just |
| 61 |
overwrite anything you mess with on the next sync. With git it will |
| 62 |
try to keep those changes around, and it might result in the tree not |
| 63 |
syncing if things conflict. If you're messing with a file for testing |
| 64 |
purposes you need to remember to reset/clean when you're done. |
| 65 |
|
| 66 |
|
| 67 |
-- |
| 68 |
Rich |
Archives