[packagekit] Things that need fixing
rnorwood at redhat.com
Fri Feb 29 06:54:22 PST 2008
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.
Red Hat, Inc.
"The Sage does nothing, yet nothing remains undone."
-Lao Tzu, Te Tao Ching
More information about the PackageKit