[packagekit] viability of the current yum backend ?

[Richard Hughes]

On Wed, 2008-01-02 at 15:45 -0500, Matthias Clasen wrote:
> On Jan 2, 2008 2:52 PM, Richard Hughes <hughsient at gmail.com> wrote:
> 
> > Well, what about just modifying the GetUpdateDetail script so that
> > multiple package_id's can be sent in one transaction (and hence process
> > invocation). The UpdateDetail signal was designed with this as an
> > "easy-to-add" option. This would mean we can populate the client
> > frontend with a single shot (on the first details click, although the
> > first response would take a little bit longer) and just cache the
> > details in the PkClient object. I don't think that would be particularly
> > tricky to add.
> 
> I guess thats the "cover up a bad design decision by caching" approach...

Well yes. We also have to keep in mind the simple backends that just
can't do the sort of processing that yum can. We just have to make sure
we don't be too much "jack of all trades, master of none".

> > Well, I'm open to ideas. Any idea has to be easy to implement for all
> > the backends (hence no dbus) and be easily testable.
> 
> I don't see at all why that is the case. Why can't you have a yum
> backend as a loadable module that communicates via dbus with a
> long-running yum process, while at the same time allowing a foobar
> backend in a different module to communicate via stdout with shell
> scripts ?

Sure, we could do that over DBUS. We just have to decide when to start
and stop it. Is the biggest issue the serialized input and output
constraining us (which I'm not sure that it does that much) or the fact
that we keep instantiating a new yum process?

> Anyway, I said I'm not going to volunteer for the rearchitecting, so I
> am going to shut up now.

Well, I agree with you, it is too slow. We just have to decide what to
do about it. :-)

Richard.