[Rpm-metadata] metadata list and discussion over tapas tonight

Daniel Veillard veillard at redhat.com
Tue Aug 5 15:13:38 UTC 2003


On Tue, Aug 05, 2003 at 08:11:48AM -0400, Peter Bowen wrote:
> > package filelists: complete file listings per package
> 
> One file per package on the server?

  Hum, no that would be unmanageable, I would think one file per
collection and association betheen the NVRE and the set of file
path it exports. But I'm still not totally convinced it's the right way.
To me extracting the File info which may be needed for resolution
and putting then in the geberal packages description file is 
the simpler way for 99.99% of the cases.

> > - send in your list of things that should appear in the non-file
> > packages listing. What data from the header is critical/useful/desired.
> 
> I think that the absolute minimum list of things that need to be in the
> file are Name, Epoch, Version, Release, Arch, package file size, and
> absolute/relative path to the package file.

  I would tend to add the short description field (the one line one),
and truncated if it happens to be too long.

> Looking at the packageinfo.xml that Red Carpet uses now, the main things
> that I see that we would want to are possibly section, pretty name,
> install only, importance, license, plus some internal information.

  Licence makes sense too, short and very important policy wise...

> Section and pretty name are simply for display purposes, section roughly
> mapping to group, and pretty name allowing the client to display a more
> friendly name for a package.
> 
> Importance is an indication of how important the update/errata is to the
> end user.  We use minor, feature, suggested, urgent, and necessary.  The
> middle three basically map to Enhancement, Bug Fix, and Security
> erratas.

  Extra informations can always be added as extra elements in a different
namespace in the XML file. Ignored by the tools unless they understand 
the semantic of the tags in that namespace.

> These are the main things that I see that Red Carpet uses that are not
> directly found in RPM headers.  We also have a couple of internal use
> fields that are essentially opaque data to the client, plus some fields
> that are duplicated from the rpm headers.  As long as we either allow
> for extra fields that some clients may not know about, or allow for XML
> Namespaces, extra data in the XML should not be problematic.

  Yup, we agree. Namespace are cleaner from a design point of view, so
taht for example Red Carpet can independantly add a "section" tag even
if the semantic does not match ...

Daniel

-- 
Daniel Veillard      | Red Hat Network https://rhn.redhat.com/
veillard at redhat.com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/


More information about the Rpm-metadata mailing list