Re: Packages.gz revamp

[Michael Urman <mu@zen.ddts.net>]

Keeping in mind the two below mentions, a method that would slightly
increase the total amount of needed space but generously decrease a
daily upgrade individual download would be nice.  The obvious brainstorm
level idea i would have is moving from:

  dists/unstable/main/binary-i386/Packages.gz
  (which we'd still need to have available for older upgraders)

to a series of:
  dists/unstable/main/binary-i386/admin/Packages.gz
  dists/unstable/main/binary-i386/base/Packages.gz
  ...

with one overarching:
  dists/unstable/main/binary­i386/Timestamps.gz

which would contain lines of the format:
  admin	    Aug  9 2000 06:45
  base      Aug 10 2000 06:41
  (or better yet a timestamp number instead of RFC822 style?)

The newer apt-get/dselect Update would know to fetch TimeStamps.gz and
fetch the corresponding updated Packages.gz of the directories below.

What's the next revision say?

-m

On Wed, Aug 09, 2000 at 12:19:39PM -0600, Bdale Garbee wrote:
> The package meta-data explosion is a real problem, and one that we
> need to work on creative technical solutions to address.  Both the
> download times over slow links for Packages information and the VM
> requirements of our package management toolset are getting out of
> control.  The best answers I have heard so far are of the "split
> Debian into a core and various optional sections" variety, and they
> still feel "icky" to me.

On Wed, Aug 09, 2000 at 10:21:08PM +0200, Christian Pernegger wrote:
> The easiest way would be to make package lists per-directory items.
> This way a user not interested in X apps doesn't even see (or
> download) them. An added benefit of splitting the packages file is
> that if only the section main/games changed, the rest of main wouldn't
> have to be fetched.

-- 
Michael Urman <mu@zen.ddts.net>
gpg: 1024g/55C56706 : C3D7 2A8F 6261 3DE4 F544  6DC3 A1D5 BEF6 156F 65A4
<mwr#debian> bsd is also responsible for porn nets, then, too? Groovy.