[packagekit] Things that need fixing

[Robin Norwood]

On Fri, 29 Feb 2008 08:59:23 +0100
Tim Lauridsen <tim.lauridsen at googlemail.com> wrote:

> Robin Norwood wrote:
> >>> 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.

Oh, neat.  I would even advocate making this the default for PK unless
there's a good reason not to.

Well, is ErrorCode intended to be for fatal errors?  If not, we can
just simply throw an error code that says: 4 of 138 updates failed to
install due to dependency issues.  <List of packages and dep error>.

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

I think for them, yet-another-separator is probably the only way.  We
just need to pick one that isn't allowed in a package name by any of
the major packaging systems for package names (or versions)

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

Is that really that bad, though?  It seems better to me to feel the pain
now, and have a cleaner API.  If the other backend owners don't like
it, we can hold off, I guess.

-RN

-- 
Robin Norwood
Red Hat, Inc.

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