Re: [gentoo-dev] Using emerge-webrsync to simplify the handbook

[Zac Medico]

On 11/28/2012 09:50 AM, Michał Górny wrote:
> On Wed, 28 Nov 2012 10:05:55 -0500
> Richard Yao <ryao@g.o> wrote:
>
>> On 11/28/2012 09:17 AM, Maxim Kammerer wrote:
>>> On Wed, Nov 28, 2012 at 3:54 PM, Richard Yao <ryao@g.o> wrote:
>>>> We could slightly simplify the handbook installation procedure if we
>>>> told people to use emerge-webrsync to fetch the initial snapshot.
>>>
>>> Using emerge-webrsync also makes the installation process more robust,
>>> since it only requires HTTP access (whereas many firewalls restrict
>>> RSYNC). Besides, emerge-webrsync can check PGP signatures, so I think
>>> that it should be the primary recommended portage tree synchronization
>>> method.
>>>
>>
>> The only downside of which I am aware is increased network traffic.
>> However, we could redesign emerge-webrsync to take advantage of GNU
>> Tar's incremental archive functionality.
>>
>> That would permit us to mirror compressed diffs in addition to regular
>> portage snapshots. Doing that well could reduce bandwidth requirements.
>
> There's emerge-delta-webrsync but it's mostly hand-work to reconstruct
> the webrsync tarball. Therefore, it is very slow and not worth
> the effort when syncing often.

At least because I maintain emerge-delta-webrsync, I use it regularly as
my sync method. Latest versions of emerge-delta-webrsync use a temp
directory inside $PORTAGE_TMPDIR/portage, on which I have a tmpfs
filesystem mounted. With tmpfs, performance does not seem so bad (using
a sandy bridge core i5 here).

> However, I'm not aware of gnu tar's incremental archive. If it's much
> faster than the above, then it should probably replace
> emerge-delta-webrsync.

If it has benefits over the current diffball approach used by
emerge-delta-webrsync, then it seems like a good idea. It would be nice
to integrate it directly into emerge-webrsync, and eventually deprecate
emerge-delta-webrsync.
-- 
Thanks,
Zac