[packagekit] Display of update details in pk-update-viewer

[Matthias Clasen]

On Jan 2, 2008 1:08 PM, Richard Hughes <hughsient at gmail.com> wrote:

> It's pretty easy to add new fields, it would take one of us a few
> minutes at most.

Plus the day that it took me to make some of the existing fields
actually work in the yum backend... anyway

> A few questions:
>
> * What exactly is update_id?

Looking at examples in F8, I see things like:

FEDORA-2007-3419

I believe the idea here is that you can find these ids e.g in lwn and
then check in the transaction history if this has been applied to your
system.

> * What sort of output would be title?

Again looking at F8, I see title only repeating the package name:

<title>tomcat5-5.5.25-1jpp.1.fc8</title>
 <title>evolution-python-0.0.4-2.fc8</title>

So this is a bit redundant and could probably be skipped for now.

> * Issue date would be encoded with iso8601?

Looks like it:   <issued date="2007-11-26 18:59:57"/>
Of course, if we didn't have to feed things through a text base
interface, this could just be a date object, and you could forget
about homegrown serialization...

> * The CVE url would be different to the update URL?

Here is what information updateinfo.xml has for references:

<reference href="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-4352"
id="CVE-2007-4352" type="cve"/>

 <reference href="https://bugzilla.redhat.com/show_bug.cgi?id=241416"
id="241416" title="paw++ crashes on startup" type="bugzilla"/>

Having this kind of information in the frontend would allow us the
render nice hyperlinks.


> Nahh, it's actually quite easy - any missing information is just omitted
> but including the delimiter.

Well, including lists of things with optional attributes (like the
above refences) gets somewhat challenging.

> You mean have low/normal/important/security/bug-fix/enhancement?

That might work. I have actually no idea how bodhi translates the
bug-fix vs enhancement vs security information into metadata.


Another piece of classification that we're missing is the stability
level; updateinfo.xml has

                <!ATTLIST update status (final|testing) "final">

I guess in the yum case this is partially redundant with the
repository information, since testing updates live in a dedicated
repository (but that may not be the case for other backends).

Of course, the actual updateinfo.xml has status="stable". Shows how
useful DTDs are when you don't validate against them, I guess...