Re: Packages file missing from unstable archive
On Thu, 27 Oct 2005 00:24:36 +0200
Joerg Jaspert <firstname.lastname@example.org> wrote:
> > Returning to the original question: Does anybody know why the
> > uncompressed "Packages" file has disappeared from the "unstable"
> > archive?
> Because relevant tools do not / should not use that file since years.
> It was announced *long* ago "to be in a few days", so now it happened.
I hadn't seen that announcement before, but it still doesn't answer the
question of "why".
As explained, I wish to use rsync (or preferably, zsync) to update the
local packages list; repeatedly downloading the 3.6MB "Packages.gz" file
over a 56kb/s link is highly undesirable. I am unable to understand why
this ambition is considered to be unreasonable.
(At this point, somebody is sure to say "because rsync imposes too much
computational load on the network servers." Shouldn't the decision of
whether or not to offer rsync access be up to the administrators of each
individual mirror? In any case, zsync is the solution to the problem; it
would decrease the servers' network load without increasing their
As far as I can see, updating the packages list with rsync requires
either an uncompressed "Packages" file, or a "Packages.gz" file
compressed with the "--rsyncable" option. Currently, neither of these
exists in the "unstable" archive (and according to that announcement,
the "testing" archive will follow). Why is rsync considered to be an
undesirable method of accessing the archive? The relative costs of
network traffic versus CPU cycles are quite different in many places
outside the United States. Why are the needs of sites with poor network
connectivity considered unimportant?
If there are any "relevant tools" which can update the package lists
without downloading the whole file, and without using rsync/zsync,
please advise me of such. I'm not committed to any particular solution
or piece of software. I just don't understand why the issue of
minimizing network traffic is thought to be universally irrelevant. Why
shouldn't there be a variety of access methods, to address the varying
situations of different client and mirror sites?
-- Ian Bruce