[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: standard apt/yum meta-data format



On Sun, 2004-07-04 at 11:12, Thiemo Seufer wrote:
> Robert Collins wrote:
> > I would not trust client clocks at all. Have the client logic look at
> > the server datestamp of the downloaded file (which as you note probably
> > should be embedded in it to handle esoteric transfer mechanisms) in
> > order to determine which 'date' it is on. 
> 
> We don't really need a date, that's just the most obvious way to get
> an unique mirror update ID. With some plans of more frequent mirror
> updates floating around, we should probably choose an ID scheme as it
> is in use for DNS zone file updates.

Agreed.

> > Also in the 'cdiff' file include the file sizes of:
> > Packages.gz
> > each delta.
> > 
> > Then the client can trivially choose the most bw efficient way to
> > receive the update.
> 
> No need for that one, if deltas larger than the original are simply not
> created on the server. AFAICS the index file should look like this:

I presume you mean deltas with an aggregate size > than the current
Packages ? 

> 20040703001	Packages.gz
> 20040702001	Packages-cdiff-20040702001.gz
> 20040701001	Packages-cdiff-20040701001.gz
> 20040630001	Packages-cdiff-20040630001.gz
> 20040629001	Packages-cdiff-20040629001.gz
> ...
> 
> with an cutoff based on cdiff size and age. That's some redundancy,
> but it simplifies processing. And apt-get doesn't have to make
> assumptions about the server's update frequency, clocks, timezones,
> etc.

I don't think that adding the file size forces apt-get to make any
assumptions about update frequency. But it does allow more client side
optimisations in the future. (There are more factors than raw size to
consider - round trips, processing overhead etc. Giving the client the
info to optimise as needed in the future makes sense to me)

Rob
-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.

Attachment: signature.asc
Description: This is a digitally signed message part


Reply to: