[packagekit] resolve_(install/remove/update) methods

Daniel Nicoletti dantti85-pk at yahoo.com.br
Tue Mar 24 19:43:07 PDT 2009


Hi, i had this discussion with Richard,
and to put my thoughts in the list i'm writing
this email.

As you know i'm creating an apt backend and because of
that i found some points that imo could be improved:

1- get_depends and get_requires, these two methods are pretty
fine for querying the pkg db looking in a gui but they don't fit
well in installing/removing tasks.
In debian we had the autoremove concept, which is also a parameter
of packagekit remove_packages, but as a parameter it does not allow
a user to see the REAL packages to be removed.

For example my g/f just installed k3b and got libfoo which is called
an automatic dependency since she didn't explicit selected it.
This made her hd usage from 100mb free to 50mb free, then she
decided she didn't want that package and a normal guess is that removing
k3b would free that space but it only freed 25mb the other 25mb
is still being used by libfoo that wasn't removed.

This is an imaginary case of course but my g/f DOES have little space
due hundreds of pictures, videos and mp3.

My proposed solution:

install/remove operations call get_depends/get_requires in recursive mode
on gpk and kpk before the actual install/remove,
so instead of these get_depends/get_requires the following new 
methods resolve_install, resolve_remove should be called
both takes a package list as an argument and emits packages
to be installed/removed.
Now removing k3b can SHOW libfoo to be removed as an unused dependencie.
(the SHOW was uppercased since we can remove libfoo silently but
it's not cool imo)

This method also makes one feature that today was aked on #packagekit
and that i myself was also thinking in when implementing get_updates.
resolve_install and resolve_remove can emit also:
download_size and installed_size which can be negative.

NOTE: Also for backends that don't support autoremove they can simply
continue to make a call to get_depends/get_requires with the proper
filters.

2- This is almost the same as above but it is for update_system and
update_packages.
Today there is no method called before these two methods, and i propose
it to also have a resolve_update why?
sometimes an update might remove installed unused packages.
for example k3b now no longer depends on libfoo.
Other times an update might install new packages which are not
part of our system already.
In the same case the NEW k3b now depends on libbar which is 
not installed.

Currently both cases will pass unseen by the user, or
the backend can forbit the update.
This resolve_update can also have
download_size and installed_size which will make
the user pretty happy to know that he can't update
now since 100mb will take too long in his
slow internet connection.
Also installed size can make gui a bit more smarter or
even packagekit by not allowing this update to happed
due lack of hd space :D

Ah now a question, this is kind of specific to my backend, i'd like to know
how can i work with media change?

Thanks all,
and please comment on these proposed new methods.

Daniel.


      Veja quais são os assuntos do momento no Yahoo! +Buscados
http://br.maisbuscados.yahoo.com



More information about the PackageKit mailing list