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

Re: [devel-ref] author/homepage in description

On Mon, 16 Dec 2002 12:12:08 +0100
Wichert Akkerman <wichert@wiggy.net> wrote:

> Previously Adam DiCarlo wrote:
> > Well, before I venture on this, is there a way we can store certain
> > data in control.tar.gz or something but without bloating the Packages
> > file?
> No.

Well, not with existing practices.

> > This does feel like a debian-devel or debian-project issue rather than
> > a policy issue, too...?
> It is relevant to the discusison though.. do we want to bloat the
> Packages file with usptream author & homepage information as well?

All data is important, but it has to be sorted/classified to be most

We currently treat all package metadata as being equally important, this
is inefficient.

Our various metadata fields have a few different targets.

System-state: Package, Version, Status, Conffiles
 These fields are unique to each installation, if the these are backed up
all other metadata can be recovered.

System-dependencies: Essential, Pre-Depends, Depends, Conflicts, Provides,
 These fields and the system-state fields are required before a package's
state can be safely changed (added/removed)

Administration:  Source, Architecture, Filename, md5sum, Size, Maintainer
 These are to assist in distribution/storage of packages.

User: Priority, Section, Installed-Size, Description, Task, Recommends,
Suggests, Enhances.
 These fields are to assist the user in choosing which packages to

The real cause of Packages bloat is not that there is too much metadata,
it is that we constantly send duplicate information.

We should not be trying to reduce the amount of metdata available to
users, we should be trying to find more efficient ways to get that
information to them.

If we made the metdata for an individual package available seperatly then
users would only need to download metadata when its changed.

This approach does introduce efficiency problems of transmitting small
files, but after a few updates it would pay for itself. 

If we split a packages metadata into multiple parts once it was downloaded
we could more easily target the needs of different packaging tools.

Storing lots of small files locally uses more disk space, this could be
overcome by splitting/joinging and/or compression on the different types
of metdata.


Reply to: