[packagekit] Display of update details in pk-update-viewer
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:
> 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
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:
> 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...
Indeed. But we need to think about the interactions with the non-dbus
> > * 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
> > 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?
More information about the PackageKit