Re: New method for Packages/Sources file updates
Adam Heath <doogie@debian.org> writes:
> On Thu, 25 Nov 2004, Goswin von Brederlow wrote:
>
>> Updating the Packages file then consists of 3 steps:
>>
>> A) download all new entries for the Packages file
>>
>> Since the Packages file are sorted by date the client just downloads
>> the file until it hits an entry it already has in the existing
>> file. At that point the client can stop downloading and prepend it
>> to the old file. Note that the client can download the gziped file
>> and gunzip it on the fly.
>>
>> This already gives a fully functional Packages file but now there
>> are some obsolete entries (which doesn't realy harm anyone).
>>
>> B) remove entries that have been superseeded by newer versions
>>
>> The package names in a Packages file are uniq [excluding
>> snapshots.debian.net here]. The client can remove all but the
>> highest version of each package to remove most obsolete entries.
>>
>> This gives nearly the right Packages file but there are still
>> entries left that have been removed completly.
>>
>> C) download the list of removed packages (again only until you hit one
>> you already have in the old removals file)
>>
>> For any new entry in the removals file remove the respective entry
>> from the Packages file. (If a package is readded later it will be
>> added again in step A and not removed here since it isn't new. The
>> package has to be removed from the removals file on the server but
>> not neccessarily on the client.)
>>
>> Now we should have a Packages file identical with the one on the
>> server. If not something went horribly wrong.
>
> 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:
1) A package update replaces all old versions (if pkname is unique as
with Debian this is the case)
The packages stanza is added to the top of the Packages file as is.
2) A package update only replaces some/none versions
The package stanza is extended with a
Removes: none | version [, ...]
3) A package is removed completly
The Packages file is prepended with the following:
Package: removals-<date>
Removals: pkgname [(version)] [, ....]
4) A previously removed package is added again
The new stanza is added to the top and the Removals entry containing
the package(/version) is modified _in-place_.
Updating clients that have already removed the package (have the
Removes/Removals stanza) have to modify the stanza in turn as well,
they won't (normaly) download it since they find a match in the
Packages file before that.
This step isn't neccessary to get a correct Packages file but purely
to reduce bloat. It's is a bit complex and we might skip it. How often
is a package removed and then added again anyway?
Does that cover all cases?
MfG
Goswin
Reply to: