[packagekit] zypper patches + packages ...

Michael Meeks michael.meeks at novell.com
Tue May 11 09:33:10 PDT 2010

Hi guys,

	So - I'm a tad confused :-)

On Fri, 2010-05-07 at 10:31 +0200, Klaus Kaempf wrote:
> > Well this is certainly not a "fix" - this is a reversal of an
> > explicit decision.  Without a patch architecture available, something
> > like that is needed but I don't think just changing the behavior of
> > the zypp backend is desired.
> If I remember correctly, this 'explicit decision' was based on
> limitations in the libzypp architecture.

	Sounds good if they are gone.

> With Code11 (openSUSE 11.x, SLES 11) we switched from our own patch
> format to rpm-md 'updateinfo.xml'.

	Great; which - I assume is what yum is using under the hood too (at
least it sounds 'shared' to me ;-)

> This provides additional data for (package) updates like
> - information why an update is needed
> - reference(s) to the fixed bugs, cve numbers, etc
> - group multiple package updates into a single 'patch' for the UI
>   (ever done a glibc update on a 64 bit system ? You'll get about a
>    dozen package updates for a single fix in glibc)


> The original proposal was to compute available package updates first
> and then use updateinfo for grouping and additional information.
> Those packages not covered by an entry in updateinfo would just appear
> as 'package update' without additional information in the UI.

	Right - currently they also appear at the lowest priority - as an
'Enhancement' I think; so hopefully less likely to be accidentally
installed & a lower priority than patches.

> However, this required to create libzypp patch objects on the fly,
> after computing available updates. Something libzypp is (was?) not
> capable of.

	Riight; well - all that aside, the code I use is (no doubt)
unbelievably nasty and is here; it's prolly simpler to review as code:


	I was slightly interested in the naming of patches (as PackageKit sees
them), we appear to return a package name:


	based on a zypp::Patch's ->satSolvable() name / ver / etc. details;
presumably it works well since it's what we did before :-) is there a
pseudo-package created for a patch ? Advice much appreciated, I have no
idea what I'm doing there (as you can probably see by now).



 michael.meeks at novell.com  <><, Pseudo Engineer, itinerant idiot

More information about the PackageKit mailing list