Re: PROPOSAL - REFORMULATED - Create alternative Packages files for each section
Goswin writes:
>
>Instead of a diff may I suggest sorting Packages in the Packages by
>date of change, i.e. add new entries to the end. We have many packages
>that don't change for a year and those entries would drift to the top.
>
>Now how does that help? The Packages file would only have minimal
>changes at the start (hopefully none in the first half or more) and
>big changes concentrated at the end. Rsyncing the Packages file would
>be improved greatly.
It'd be better to sort them the other way[1], but even then you have
problems with removals.
>One could also write a server (cgi script?) that, given the last entry
>in the clients Packages file, sends all entries (new packages) after
>that entry. The client would then add that to its Packages file (and
>possibly remove the obsolete entries).
No. You don't want to have to rely on anything more than what is
currently pushed out to the mirrors via
FTP/HTTP/rsync/whatever. Otherwise we introduce a bottleneck with that
CGI.
AJ's pdiff proposal is the right answer to the problem of minimising
Packages file downloads as far as I can see [2][3], and just needs
somebody to implement it.
[1] http://blog.einval.com/2004/08/08#packages-files
[2] http://azure.humbug.org.au/~aj/blog/2004/08/09#2004-08-09-wheels
[3] http://blog.einval.com/2004/08/19#packages-files2
--
Steve McIntyre, Cambridge, UK. steve@einval.com
"I can't ever sleep on planes ... call it irrational if you like, but I'm
afraid I'll miss my stop" -- Vivek Dasmohapatra
Reply to: