[packagekit] PackageKit Apt support

[Daniel Nicoletti]

Hi list,

After some discussion today on irc, here's an email
resuming things.

I have studied synaptic, aptitude and apt-* code and
to create Aptcc, as you know aptcc can do almost everything
but install/remove/update, that because I want to solve
first the problems that apt vs Pk implies, and finally I found
the solutions to every problem python apt found.

They are:
- Debconf dialogs
- Conffiles
- Properly showing what is going to happen.

For Debconf dialogs I've found that as python apt
does use the Non-interactive mode, BUT in this mode
some packages fail (ie java-jre6).
The solution is simple, create a new PackageKit method
packagesPendingConfiguration(pkgs...), and emit, the client
GPK or KPK will call the a helper app that will show the
debconfs to the user and he will be happy :D, additionally
it could have a pool (maybe implemented in the backend)
so the user can be warned if non-configured packages are
still pending.

Conffiles, this one happens when you or a script changed
the .conf file of a give app, then when installing a newer version
of it might conflict, as we can't wait for the user to reply immediatly 
we can again let that be done later.
The solution is detect a conffile call (simple) and automattically answer the
default "keep the current version", and store the file
at the end  of the installation emit packageConfigChanges(file, maybe files).
Now the gui to can Call a helper app that deals with that Or 
ask the question itself and send the replies to the backend.
The backend just need to move the new config over the old one.

The last one and very important imo is to properly shows
what is going to happen. To understand this one I'll present the
same use cases I proposed in my lasts "simulate" emails:

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>.
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
}
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Ok, why this is important?
because with this Debian users don't need to
go to the CMD line to see what's going to happen
in any of those cases.

The ui would group the packages just when packages
have different tags, like to be removed and updated.
It would be "a bit" more complicaded, but still much
easier than cmd Line.

I can try to implement this method but I want
Richard's approval and help and/or ideas on how
to finish this.

Really if all this could be done I bet soon enough
Pk would be available to Debian/Ubuntu and be much
more welcomed :D

Thanks,
Daniel.


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