[packagekit] Questions for PK and future zypp backend development

[Richard Hughes]

On Thu, 2008-01-10 at 15:09 -0700, Boyd Timothy wrote:
> Sorry I've been absent for so long from PackageKit.  I spent a good
> week doing some Tomboy hacking and then of course there was Christmas,
> etc.

No need to apologize - we are all busy with Real Life Stuff (tm).

> Anyhow, I started to get back into it this week.  I've had a couple
> conversations with the Zypp team which has resulted in some questions
> that I don't have the answers to and wondered if you might have them.
> Some of my questions might have too obvious of answers, but I don't
> have the answers because I haven't fully implemented the zypp backend
> to see the results.

No problem.

> 1) Stateless backends?
> 
> It appears that for almost every call, a new instance of zypp is
> instantiated.  This may not seem too bad, but the problem is that I'm
> having to do so much setup work in the first place to make even simple
> calls to find out information about a package.  Some of this is being
> worked on in libzypp right now, but I wondered if there's a better way
> to maybe persist or reuse a currently instantiated zypp backend.  I
> read through the discussion about the yum backend and it seems writing
> up my own caching scheme in the zypp backend might be a bad idea...but
> at least it would speed things up some and help keep state.

Yes, I'm thinking on this. We can't rely on the backend instance being
around for all of packagekitd, but trust me I'll be making some big
changes in packagekitd after the next release. It'll involve getting rid
of the smart queue (or at least making it a hell of a lot simpler) and
hopefully keeping the backend instance alive while there are queued
transactions (and maybe a little more).

This should make the interactions with the daemon an order of magnitude
faster.

> An example of this is when you run pk-application.  First, you search
> for a package and that takes a while.  Then, you select the package,
> and packagekit makes another (new) call to the zypp backend which has
> to resolve the package again just to get the package description.
> Maybe someone from the yum backend could explain how they're
> overcoming stuff like this?

Well, I think yum just sets up fast ;-)

Seriously, yum's doing nothing special, it also is initialized on each
invocation. See above :-)

> 2) What is the expected behavior in PackageKit when multiple
> vendors/repositories provide the same version of a package?  Do both
> packages show up in the GUI?

I think so.

> Also, during automatic dependency
> resolving, if "Package B", required by "Package A" is found from
> multiple repositories, is there any logic to determine which
> repository "Package B" is installed from?  Pointed out to me earlier
> today in #yast involves downgrading a package and installing 32-bit
> versions of some software for compatibility issues.

Well, I would argue that's a packaging problem, not something the user
should worry about. How does the zypp command line client decide what
should be installed?

> 3) Has repository priority been considered?  You know, so I could say,
> trust this repository more than that one?

Well, I don't think we need to, i.e. packagekitd knows nothing about
repos, and leaves all that sort of nitty gritty to the backend to deal
with.

> 4) On a GetDescription () call that would potentially result in
> returning 30 packages (all of the same version) from 30 different
> repositories, which one should be used for returning the description
> results?

Well, GetDescription takes a package_id as an input, and each package of
identical name and version (in different repos) should have a different
data field (with the repo name in it).

> 5) What is the expected behavior when "Package A" lists a specific
> library as a requires, e.g., libFoo.so.4, which happens to be provided
> by 30 different packages.  Which package should be returned so
> libFoo.so.4 gets installed?

What would be installed if you tried to install it using the native
tools? IIRC yum uses a heuristic to pick one, which is probably what you
guys already do.

I hope that helps,

Richard.