[packagekit] Things that need fixing

[Robin Norwood]

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

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.

Thoughts, rants, flames?

-RN

-- 
Robin Norwood
Red Hat, Inc.

"The Sage does nothing, yet nothing remains undone."
-Lao Tzu, Te Tao Ching