On Mon, 16 Dec 2002 12:12:08 +0100 Wichert Akkerman <[EMAIL PROTECTED]> 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