[packagekit] PackageKit Apt backend patch

[Tom Parker]

On 04/12/2007, Sebastian Heinlein <glatzor at ubuntu.com> wrote:
> Am Dienstag, den 04.12.2007, 00:12 +0100 schrieb Tom Parker:
> > On 03/12/2007, Mario <mario.danic at gmail.com> wrote:
> > > here's a quick patch for Apt backend written by Michael Vogt.
> > > It mainly cleans up the code by removing duplicated functionality
> > > for code which already exists in python-apt and it's "apt" module.

I've just committed that.

> Take a look at the SetCandidateVer method of depcache.

Doesn't seem to work (using python-apt 0.7.3.1+b1 on a Debian system).
Using SetCandidateVer, then testing with GetCandidateVer gets me the
old candidate version back, not the new one I just told it. Return
value is 1 (which AFAIK is "ok"). Can't figure out what I need to do
to tell it "just do what I tell you to".

> But why do you want to do this at all? Overriding the candidate version
> should only be done in some rare cases. I don't see the need for such a
> feature. AFAIK there isn't any distribution which provides data
> migration for downgrades.

More for upgrades than downgrades. For example (from my own
experiences this morning) Pidgin just released a new version. Now, I
don't particularly want an entirely "unstable" system, but for a few
packages like Pidgin, I'd like the latest and greatest. I want my
system to get the minimum set of upgrades necessary to do the new
stuff, with a minimum of disruption for everything else. Principle of
least surprise and all that.

In a more general sense, we're spitting out full PackageKit package
id's, which include version information, and if a user asks to install
a particular version of a package, they may well be not so happy if we
install a different version. One way around this is to only output the
candidate version edition of a package, and ignore everything else,
but I don't like that workaround.

Tom