[packagekit] Adding support for "prepare" in transaction_flags

[Sebastian Heinlein]

Am Sonntag, den 03.06.2012, 16:03 -0300 schrieb Daniel Nicoletti: 
> 2012/6/3 Matthias Klumpp <matthias at tenstral.net>:
> > I really liked the suggestion for all stuff like RemovePackages()
> > InstallPackages() etc. to just enqueue the actions and one new
> > "Commit()" signal to really apply the changes.
> > This would solve the issues, but to implement it properly, backend and
> > frontend APIs would have to be broken, which is not ideal.
> Well right now pretty much everything is broken, even the
> install/remove/update methods, so creating this method would
> imo bring some goodies, I can only tell by apt, but maybe
> other backends could make use of that too.

Aptdaemon features a CommitPackages() method (but I am also not very
happy with the name). The method accepts arrays of strings of package
names for each operation: install, update, remove, purge, downgrade.
(Optionally and in the case of downgrade mandatory a target version can
be specified [1].

As stated on IRC the benefit is that even sophisticated package managers
could use a PolicyKit driven backend without having to re-event the
wheel, yast, Synaptic etc.

We reduced the number of used policykit privileges some time ago and
only use install-or-remove-packages, install-local-file and
update-packages privileges for the basic package install/removal/upgrade
operations, see [2].

If only upgrades are requested in a CommitPackages() call we only
require the upgrade-packages privilege otherwise the
install-or-remove-packages is required. The reason is very simple:
install operations also allow to remove packages in APT e.g. installing
exim would remove a postfix installed by the admin or other newly
installed packages could drop configuration files. We don't see a valid
use case for only granting an user the privilege to install but not to
remove packages - they can be both dangerous. So we set the focus on the
source of the packages:

Are the packages from a source configured by default or by an admin? Or
does the user want to install software from a third party repository or
even a local one?

To modify repositories the change-repositories privilege is required.
The update-cache and upgrade-packages privilege are granted to any
active desktop user by default. It makes sense to allow users keeping
the system up-to-date but not to install or remove any of the software.

Moreover we introduced the high level privileges
install-packages-from-new-repository which the client authenticates for
before calling the aptdaemon methods to get the privilege cached by
policykit. The privilege includes the change-repositories, update-cache,
and install-packages privilege. An equivalent is available for
purchasing packages. So in the end installing from a PPA requires only a
single authentication.

Cheers,

Sebastian

[1] http://packages.python.org/aptdaemon/dbus.html
[2]
http://bazaar.launchpad.net/~aptdaemon-developers/aptdaemon/main/view/head:/data/org.debian.apt.policy.in
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freedesktop.org/archives/packagekit/attachments/20120604/25ef5df9/attachment.pgp>