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>.
Attachment:
signature.asc
Description: This is a digitally signed message part