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

Richard Hughes hughsient at gmail.com
Wed Jan 2 11:47:09 PST 2008


On Wed, 2008-01-02 at 13:34 -0500, Matthias Clasen wrote:
> 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

Ahh yes, sorry.

> > 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.

Okay, what about calling it vendor_id?

> > * 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.

Sure.

> > * 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...

Indeed. But we need to think about the interactions with the non-dbus
capable backends.

> > * 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.

Sure, so make url into bugzilla_url and bugzilla_name and cve_url and
cve_name?

> > 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.

Well, with a python helper function it's pretty trivial imo.

> > 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.

Luke, Robin, Tim, James?

>                 <!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...

Is this information useful to the end user? Feedback?

Richard.





More information about the PackageKit mailing list