[packagekit] Things that need fixing

[Tim Lauridsen]

Robin Norwood wrote:
> On Tue, 26 Feb 2008 14:36:32 -0500
> Robin Norwood <rnorwood at redhat.com> wrote:
> 
>> On Tue, 26 Feb 2008 20:21:02 +0100
>> Richard Hughes <hughsient at gmail.com> wrote:
>>
>>> On Tue, 2008-02-26 at 14:02 -0500, Robin Norwood wrote:
>>>> This seems a little funny to me for some reason.  I think it's
>>>> because of my background with webapps - for instance, whenever you
>>>> see someone putting a bunch of separated values in a single column
>>>> in a DB table, you know they're Doing It Wrong.  OTOH, it's nice
>>>> to be able to pass additional data around without breaking the
>>>> API...
>>> Sure, it's just the same stuff we pass as a filter. We could do the
>>> same as an "as" signature - it's just less hassle to pass as a well
>>> formed string. I guess you've got the draw the line somewhere
>>> between correctness and API ease of use.
>> You're probably right, that sort of thing just sets of warning bells
>> for me.  I'll see if I can get that today.
>>
>>>> Don't tell him, you'll just encourage him.  I think we should add
>>>> checkboxes For Now, until someone figures out how to do it better
>>>> in various backends.  Then we can add the 'do the right thing'
>>>> button.
>>> Well, DTRT should be done in UpdateSystem.
>> Yeah.  And send error signals for the packages removed from the
>> transaction.  Tim L. or one of the other yum guys probably knows
>> better than I how feasible DTRT is with yum's API.  I'm guessing the
>> standard case of 'update of LibFoo-X.Y from repo Bar breaks because
>> app Blinky requires LibFoo=X-1.0' is fairly easy, but edge cases
>> devolve into a horrible mess very quickly.

Yum >= 3.2,10 has a new improved '--skip-broken' broken feature builtin
to skip packages with broken dependencies.
it is controlled by the self.yumbase.conf.skip_broken flag.

I would be nice if there was some way to control this from pk, but we 
have to extend the signals some how to signal packages being skipped 
from the transaction.
Good ideas welcome.
>>
>>>> I don't like this at all.  The backend is going to need to handle
>>>> each of the possible cases differently, and might not (yet)
>>>> support a given action over multiple packages.  With something
>>>> generic like this, there's no way to say "I support upgrading, or
>>>> installing a bunch of packages, but not downgrading or removing"
>>>> for instance.
>>> Sure, valid point.
>> So you think separate UpdatePackages, InstallPackages, RemovePackages
>> calls?  Maybe just change *Package -> *Packages and just send a single
>> package to make things work like they do now?
> 
> I've looked at this a bit more, and it looks pretty feasible to have
> the engine send arrays over dbus instead of strings.  Each element a
> string defining a package the same way we do now.  The dbus-python
> bindings seem to support catching the arrays on that end.
> 
> Or, we could just spooge together the package definitions with
> yet-another-separator.

In the yum2 backend i make perfect sense to use arrays, but what about 
the helper script backends link yum, how do they handle multiple packages ?

> 
> The other question is, do we keep the single-package methods and add
> multi-package methods, or just change all of the single-package methods
> so they handle arrays of packages?  I prefer the latter.  We might need
> to change some of the signals returned so we specify what package we're
> talking about.
>

I think we should make new multi package method, and let the frontend 
check if multi package methods is implemented, then use them else 
fallback to single package methods.
I the yum2 backend we only implement the multi package methods.
InstallPackage : single
InstallPackages : multi (or maybe just Install)

If we just update InstallPackage to support multi packages then we have 
to fix all backends at once to support multi packages.

Tim