[packagekit] Res: Res: New backend

Daniel Nicoletti dantti85-pk at yahoo.com.br
Tue Jan 6 18:45:39 PST 2009

>The problem is the non interactiveness of a running PackageKit
>- no conflict resolving of configuration files
>- no media support (cdrom/dvd)
>- no debconf support
>The main issue of the python backend implementation is currently the
>speed of sending a large list of packages. GetPackages is very slow
>compared to the spawned backends. This could be a problem in the
>dbus-backend or the python backend code. I turned the dbus apt backend
>into a spawned one for testing sometime ago and it was as fast as the
>other ones.

yep, made a bounch of testing in both backends with the same hw, same
cpuload... and getPackages here takes 2x and some 3x more time
like a ./pkcon getPackages > packages
is taking 25 ~35 seconds with c++ while 
py is taking 50 ~ 70 secs also i noticed that py takes a lot of time before
start sending packages.

but really the speed is not The matter imo but the mem usage, i find it too high.
1-2 secs in a search is acceptable but 60mb of my ram is not, i have a old sony vaio
that has 256mb and without any program running except the desktop it have about
~60 free.. i whish i can use pk in that old pc :D

about the search improvements i find it very usefull search for packages
like  openoffice.org2-kde which is a virtual package and receive
openoffice.org-kde which is the package provided by oo2..

>For the SearchDetails method we make optionally use of apt-xapian-index
>which is really fast. One problem of apt-xapian-index is the
>synchronization after a cache refresh, that takes quite some time
>currently. The potential of a-x-i is not yet used: it allows to reinject
>the search by taking the debtags of the first results into account. So
>searching for a "graphics editor" would give you back gimp (image
>editor). And this with nearly instant results.

i agree that it's really fast and i plan to add support on that in the future
xapian is cool but i would let a backgroud app do the update job..
sometimes seens that the py backend frooze because of rebuilding index...
btw i was comparing getPackages result and i found a bug in my backend
and one in yours :P
mine is simple and i'm fixing now.. ( i was emmiting the wrong version as i have
apt pinning set up here) and py one is that i have a Unknown package emmited
and that packages is a plus my list has 25510 pkgs and py has 25511 :P
i don't have any idea where is this pkg comming from but if you whish i can try
to do some tests...

>Learning python is not hard. You could do this in a week. There are even
>some Python-in-24-hours tutorials :) Also python-apt could be a nice
>working place for a c-coder.
yep, i know py is easy actualy i had also given classes of py also
worked with django but after a while working with it i found some stuff that
make avoid it..

>It would be nice if you could share some more of your ideas. Since for
>me it won't make sense to work on a Python backend if you can provide a
>better one written in C++.
well as we have aptitude, apt-get, synaptic code in c++ i'm finding it really
fast to understand adpt and copy and polish so i believe this will be fast,
my main idea in this backend is to provide some way to send Finish(transaction
has uncofigured packages.) sth like that and the user can fire some action that
calls the piece of code synaptic uses. Actually as i said before CTRL + C and
ctrl + d normally works and leave the pkg unconfigured, they don't crash my
db as ctrl + c is just a kill signal so aptitude knows how to close..
but i don't know if this can work in the backend..
i know that i need to learn :P i'll commit this backend asap i don't have much time
and i'm trying to get it in good shape..

about the testing the infraestructure there are some c++ testers as Adrien uses
some of them, but i'm not a guy with this knowleged i normally test all my code
by doing mind tests... they work pretty well but in a cooperative enviroment
i believe we will need some testing stuff..


      Veja quais são os assuntos do momento no Yahoo! +Buscados

More information about the PackageKit mailing list