[Rpm-metadata] two other areas needed

[Jeff Licquia]

On Sat, 2003-10-04 at 03:01, seth vidal wrote:
> I think the idea we got fairly comfortable with was:
> 
>  handful of files idea - this is adrian's - the idea is to have 3 or 4
> files which house all the data. 

This is exactly how apt works, all the way down to each file's purpose.
 
I'll give you URLs for the files as apt does them.

> The first file maybe lists the
> channels/repositories and checksums on them - that way if that file has
> changed you know if you need to get the others. 

http://archive.progeny.com/debian/dists/woody/Release

This file contains other metadata as well regarding the distribution
that can be used by apt to make decisions about which packages to
install.

Also note Release.gpg in that same location; this is how Debian
currently secures apt repositories.  Essentially, we sign the entire
distribution.

> The second is the file I
> posted a little bit ago - the main package information file. 

http://archive.progeny.com/debian/dists/woody/main/binary-i386/Packages

(also .gz, .bz2)

> The third
> is a file containing the complete list of all the files for every
> package. 

http://archive.progeny.com/debian/dists/woody/Contents-i386.gz

> I'd like to recommend maybe including a fourth which might contain
> 'other, misc information - for example the complete changelogs or
> somesuch things'. Matthias Saou recommended this b/c he would like an
> easy way to do index generation of remote sites. He thinks the changelog
> information is useful and would like for it to be indexed. I explained
> that putting it in the main file would be wasteful of space and just
> bloat things up too much, however, putting it in an additional file,
> especially one that is not called on unless someone happens to want/need
> the changelog data, might be entirely reasonable.

In Debian, we have something called "apt-listchanges".  This utility
hooks into apt after updates are downloaded, looks at the current
versions of installed packages and their updates, extracts the changelog
sections for all the updates between the two, and displays them to the
user before doing the upgrade.  You can abort the install after
reviewing the changelogs.

IMHO, listchanges add-ons like this would be the better way for people
to review changelog data during install.  Downloading just the changed
packages and extracting the changelog before install takes a lot less
bandwidth than a file containing every changelog in the distribution.