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
usefull.
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,
Replace.
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
install.
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.
Glenn
Reply to: