| Robert Collins 2004-07-03, 7:00 pm |
| On Sat, 2004-07-03 at 10:38, Mike Fedyk wrote:
> Hopefully it's multiple files will allow apt-get update to download only
> the changes instead of the entire list over and over.
>
> I know it could be done by splitting the files per month/week/day or
> etc, if it can make the updates download less data, and counter the NIH
> problem yum developers seem to have I'm all for it.
A journalled approach is probably a whole lot easier than vertical-split
file approach. Having a central index (repomd.xml) doesn't reduce the
big O growth of the daily-check download size at all for distributions
that are dynamic - like testing|unstable|gentoo|bsd-current. It does
reduce the number of roundtrips for the common case on 'frozen' releases
like stable (rather than check a couple of file timestamps, download one
1K file with them in it). AIUI the download size for dynamic
distributions using the debian repository format is essentially linear
to the number of packages in the Packages.gz model, not proportional in
any sense to the number of changes. And thats something not addressed in
that readme.metadata proposal. Its also essentially orthogonal to that
proposal.
> Unfortunately, from what I can see in the readme[1], it doesn't look
> like the "apt-get update downloading less data" has been a consideration.
>
> 1. http://linux.duke.edu/projects/metadata/readme.metadata
I think it has been, but IMO they haven't gotten an effective answer.
XML is no more extensible than RFC2822 - I think that the xml aspect is
irrelevant except in cost-of-migration.
Rob
--
GPG key available at: <http://www.robertcollins.net/keys.txt>.
|