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

Re: New method for Packages/Sources file updates



Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de> writes:

> Goswin von Brederlow wrote:
> [snip]
>> > Packages files can continue multiple entries for a package.  With different
>> > versions.  Maybe even with different files(not certain about this latter).
>> >
>> > You can't use just the pkgname as the primary key.
>> 
>> Following Seteves idea of marking removals in the Packages file itself
>> I've come up with the following:
>
> I think the whole approach is needlessly complicated. Could you
> read the idea covered in the thread starting at
> http://lists.debian.org/debian-devel/2004/07/msg00128.html
> and explain what's wrong with it in your opinion?
>
>
> Thiemo

+ no performance difference for daily updates (+- a few bytes)

- preformance penalty for repeated patching of the same package
  (e.g. the zsh-beta upload every odd day)

- compression penalty due to lots of small files instead of one big
  one from gzip, even worse with bzip2

- performance penalty due to lots of small files instead of one big
  one from apt-method, forking gunzip, forking patch

- multi pass method where a failure in any one of them is fatal

- timestamp on package is timezone/clock dependent but the index
  should protect that

- extra space needed for the diff files

- limited update interval to stop the extra space from exploding,
  2 weeks suggested while my method can cover full releases for a few
  K extra

- new files that mirrors won't pick up for a long time,
  can only be used on mirrors that are reconfigured to mirror diffs too

- no benefit for rsync or zsync

- not applicable (due to number of files) to archives with hourly
  updates (like amd64, and we might even do 15m updates to prevent
  Build-Depends stalls)

- probably unusable on snapshots.debian.net like archives with tons of
  Packages files due to too many tiny files


Need any more? :)

MfG
        Goswin



Reply to: