[Rpm-metadata] versioning for updateinfo.xml

[James Antill]

On Tue, 2009-05-12 at 13:25 +0200, Duncan Mac-Vicar Prett wrote:
> Seth Vidal wrote:
> >> Hi guys, is there any versioning tag defined to version the
> >> updateinfo.xml file? any plan yet how to handle future formats to the
> >> file?
> >>
> > 
> > We could version it in the repomd.xml like we do with the dbversion of
> > the sqlite dbs. What enhancements to the updateinfo.xml format are you
> > suggested that you would need a versioned file for?
> 
> Right now none that we would like to introduce immediately. (especially
> since most changes would need to be implemented in ZYpp at the same time
> as in upstream yum) But if we add changes in the future we want to make
> sure applications wont break.
> 
> May be we can add a common <data-version> tag for data resources and
> agree that if the tag is not there then we assume 1 ?

 Sure, we could do, but depending on what the change is that it doesn't
seem worth it.

> Changes I would like to see in the future for updateinfo.xml is the
> split of severity and priority
> http://lists.baseurl.org/pipermail/rpm-metadata/2008-December/001017.html
> 
> And for general rpmmd, lzma support:
> http://lists.baseurl.org/pipermail/yum/2009-April/022625.html
> 
> is that one hard to implement in current yum?

 I'd say there are three ways of doing a change:

1. Just add extra tags/attributes, all the XML parsers should cope so
this'll be forwards and backwards compatible.

2. Add a version tag. This is problematic, as you have to download the
file before you see it and anything old enough that doesn't know about
it is screwed (thus. no compatibility).

3. Add a new type to the repomd.xml, so you'd have updateinfo and
updateinfo-2009 ... this is forwards and backwards compatible, but means
the server side needs to create/manage two sets of data.

...I'd assume that the severity/priority thing could be done as #1, and
the lzma thing would need to be a #3 (if it's worth it). I'm not sure
what would be #2.

 The big problems with adding LZMA support to yum is that there's no
lzma module in core python, and that we'd need to change the types for
everything we wanted under it. Plus the fact that having 3 different C
implementations of lzma doesn't thrill me.

-- 
James Antill <james at fedoraproject.org>
Fedora