[packagekit] Simulate action (was resolve_*)

[Daniel Nicoletti]

Ok, none of you replied to my first email
so i'll try to make it easier to understand.
First the use cases, these use cases you will certainly found
in Debian system, probably others too:

1. The user wan't to update k3b 1.5 to 2.0.
Today we do updatePackage(k3b).
PROBLEM: the new k3b 2.0 no longer depends on cdrdao,, and it depends on
dvdrw-tools > 1.0, and it now depends on blue-ray-disk.
So the way PK work today, the user won't see that dvdrw-tools
must and will be update, neither he sees that the unused dep (cdrdao) will be removed
(of course if it's not being used by any other package) AND that a new package (blue-ray-disk)
will be installed.
Proposed:
simulate(UPDATE_ROLE, pkg_ids);
Will emit packages to be removed, installed and updated.
so if we can show a sumary dialog showing what will happen:
1 new install
- blue-ray-disk
1 remove
- cdrdao
1 update
- dvdrw-tools.
After the ui show this and the user click continue we do
the usual update_package(k3b).

2. The user wants to remove libdvdread.
PROBLEM: the mplayer pkg depends on at least one dvd reader,
which can be libdvdread OR libcss, libdvdread also installed liblow-level-dvd
which was marked as Automatic installed (when we installed)
and no other installed app is using this lib.
Again the way Pk work today we would do get_required_by(RECURSIVE)
and we would see what packages libdvdread depends, we would find mplayer,
but mplayer can use libcss so we can ask for install,
and we would not find that the unused lib-low-leve-dvd will be automatic
removed (as no other package is using it).
Proposed:
simulate(REMOVE_ROLE, pkg_ids);
would show:
1 remove
- liblow-level-dvd
1 new install
- libcss
The libcss now fills the libdvdread gap, and the user can see
what will really happen.
As usual after clicking continue we just call
remove_pkgs(libdvdread);

3- The user wants to install firefox
PROBLEM: firefox conflics with Internet Explorer :P
ok ok, i'm joking but there are packages that can't coexist
So we call get_depends(firefox, RECURSIVE),
we see what it depends, hit Continue and suddently our
lovely internet explorer is removed. Cause it could not coexist.
Well, this can be "fixed" by failing and saying that the user
must remove internet explorer OR
we could do:
simulate(INSTALL_ROLE, pkg_ids);
would show:
2 remove
- internet explorer
- ie lib
1 new installed
- firefox lib


OK, i hope i was clear enough that getDepends and getRequired both in recursive
don't fit all the cases in apt, i really believe others systems such as yum would
have problems like these too.
This proposed CHANGE is really no big deal for backends
what all of then would need to do
simulate(role, pkgs_id)
{
switch(role) {
case install:
       get_requires(pkgs_id)
case remove:
       get_depends(pkgs_id)
case update:
    do nothing
}

Now distros that want to have they customized can do it.
I forgot just one thing, we could also have a signal
donwload_installed_size(donwload size, installed size)
So that at the end of simulate we show: 30mb to download/100 wil be used after installing
and be able to sorry you don't have enough space.

Please comments,
Daniel.



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