Gentoo Archives: gentoo-portage-dev

From: Mark Kubacki <wmark@×××××××××.de>
To: gentoo-portage-dev@l.g.o
Subject: [gentoo-portage-dev] [PATCH] portage: HTTP if-modified-since and compression
Date: Thu, 02 Aug 2012 00:09:08
1 Hi Portage devs,
3 The attached patches fix some issues I've noticed as maintainer and
4 user of Gentoo binhost(s). They're made against master/HEAD and can
5 easily be backported to 2.1*.
7 The first patch enables Portage to skip downloading a remote index if
8 the local copy is recent enough. E.g., the remote index didn't change
9 between to "emerge"-runs. This is done by setting "If-Modified-Since"
10 request-header. The server responds with HTTP code 304 and Portage
11 doesn't even load a single byte of the (large) index file.
13 By the second patch Portage will download remote indices—which are
14 text-files after all—compressed, if the remote server supports that.
15 Although de-compression introduces a small latency, this will save
16 bandwidth and transmission time. If the index needs to be fetched at
17 all, that is (see the patch above).
19 An index' TIMESTAMP entry is set before the corresponding file gets
20 written. If the difference between TIMESTAMP and modification time
21 ("mtime") is greater than or the times span one second, remote index
22 files will be loaded despite the "If-Modified-Since" header. This is
23 because TIMESTAMP of the local copy is compared with the remote index'
24 "mtime". The third patch fixes that by setting "mtime" = TIMESTAMP.
26 --
27 Mark


File name MIME type
0001-Use-If-Modified-Since-HTTP-header-and-avoid-download.patch application/octet-stream
0002-Add-support-for-HTTP-compression-bzip2-gzip-and-defl.patch application/octet-stream
0003-Fix-index-file-s-mtime-which-can-differ-from-TIMESTA.patch application/octet-stream