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: