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

Re: PROPOSAL - REFORMULATED - Create alternative Packages files for each section



Michelle Konzack <linux4michelle@freenet.de> writes:

> Am 2004-08-27 02:54:37, schrieb Felipe Augusto van de Wiel (faw):
>
>> 	We could keep the Packages file for backward
>> compatibility. Perhaps we can compress it? Or create
>> a compressed version?
>
> It IS already compressed... 
>
> In the Mirror (today, main) there are:
>
> WOODY:	Packages	 6.531.974 Bytes
> WOODY:	Packages.gz	 1.774.018 Bytes
>
> SARGE:	Packages	11.879.329 Bytes
> SARGE:	Packages.gz	 3.057.427 Bytes
>
> I think, this is quiet aceptable
>
> SID:	Packages	12.614.196 Bytes
> SID:	Packages.bz2	 2.465.740 Bytes
> SID:	Packages.gz	 3.219.380 Bytes 
>
> Here we can make based Weekly or TWO-Weekly full Packages and 
> then a daily diff wit the updates Packages.

Instead of a diff may I suggest sorting Packages in the Packages by
date of change, i.e. add new entries to the end. We have many packages
that don't change for a year and those entries would drift to the top.

Now how does that help? The Packages file would only have minimal
changes at the start (hopefully none in the first half or more) and
big changes concentrated at the end. Rsyncing the Packages file would
be improved greatly.

One could also write a server (cgi script?) that, given the last entry
in the clients Packages file, sends all entries (new packages) after
that entry. The client would then add that to its Packages file (and
possibly remove the obsolete entries).

>> 	And what about to use alternative "storage"
>> like DBs and XML? We have SQLite that could be useful.
>
> Too blown...
>
>> Anyway, probably would be better if we provide some
>> alternative to Sarge and try to find a better solution
>> to stable-after-sarge.
>
> Maybe...
>
>> 	I also think in split Packages file fields
>> and create an index between then, build a Depends file
>> that should be used to keep the consistency.
>
> Or a Packages file with the normal Headers and one
> for the Desription...

And the description file would be localized.

>> 	Well, just a few ideas in the brainstorm.
>> 
>> 	Best regards,
>
>
> Greetings
> Michelle

MfG
        Goswin



Reply to: