Re: intent to package mrename
On Wed, Aug 09, 2000 at 12:19:39PM -0600, Bdale Garbee wrote:
>
> The package meta-data explosion is a real problem, and one that we need to
> work on creative technical solutions to address. Both the download times over
I haven't seen them mentioned yet, but there are several solutions to
this (both current and potential) based on rsync. The rsync-based solutions
work at a finer granularity (about 800 bytes), so they should have even
lower bandwidth requirements than the proposed Packages.gz hierarchy.
1) exists - use Stephen Rothwell's _ (forgets the name) little proxy
that intercepts requests for Packages.gz and instead rsyncs a
Packages file.
2) almost exists - Modify apt to download Packages instead of
Packages.gz via an rproxy tunnel.
3) a native apt rsync method
4) use an rsync-enhanced web cache and rsyncable files
rproxy exists, rsync-enhanced apache is apparently in progress, and
rsync-squid is on the wishlist I hear. A modification to gzip that
yields rsyncable .gz's is possible as well, but it has an overhead
that may not be desireable. Raw text is very rsyncable. Binaries
show significant overlap between revisions (50-80% typical?) .bz2's
will never be rsyncable. Or skip cache and put rsync-http features
directly into apt.
Drifting further afield: it would be good if the new signed-debs proposal
being worked on signed uncompressed tarballs rather than the compressed
ones. This would make more options available later to switch compression
methods retroactively - especially for dedicated rsync-only mirrors.
Refs: http://www.linuxcare.com.au/rproxy/
Reply to: