[packagekit] Status of the APT backend

[Richard Hughes]

On Thu, 2008-02-21 at 17:08 +0100, Sebastian Heinlein wrote:
> Updating the system is a different use case as installing or removing an
> application.

Totally agree.

> So I don't see the need to combine these items in one user
> interface. It would be nice to even separate the installing and removing
> of applications. Novell did a nice job by allowing to remove
> applications with a right click on the menu item. But this is too hard
> to discover.

Yup, although we could add a trivial pk-remove-applicaion-by-file for
this case (where we pass it the .desktop file as an argument) and let
distros make the decision to enable it or not. It's a five minute job to
create an application like that.

> I don't see a reason to provide a graphical user interface for average
> people that deals with packages and not with applications. Situations in
> which average people are confronted with packages should be avoided at
> all, e.g. howtos should use nice one-click-install buttons on the web
> site (apt-url). Dealing with packages definitely belongs to the power
> user area.

Sure. I was thinking about the one-click install problem last night. I
think we need a way to trigger a package install (from the native
package repos) from a URL. Obviously we would need the prompt, and
another PolicyKit role with suitable warnings. I was thinking of
something like:

FILENAME: install-a-good-browser.pkautoinstall
[auto-install]
PackageNames=epiphany;epiphany-browser
PackageFiles=/usr/bin/epiphany;/usr/bin/epiphany-bin

Where all these are hints to the package backend as there may be
different names for packages on distributions. If the name can't be
found, then the tool could fall back to searching by path for the
correct package. This way we can get on-click install working on all the
distros in an abstract way, and have links like this in howtos.

There's no point putting in Summary or any other information, as we need
to get these from the trusted repo, not a untrusted file.

> >       * properly separating the UI and the APT backend.
> > So that would mean, basically, redeveloping PackageKit. 
> > 
> > I don’t understand why PackageKit wouldn’t be suitable to replace it.
> > If it can search packages, install and remove them, upgrade packages or
> > the distribution as a whole, there is no reason why it couldn’t do the
> > job.
> 
> The question is if would you like to use packagekit as a central
> software installation daemon. And still rely on apt based applications
> for queueing actions.

It's a good and important question. I do see the need for tools such as
synaptic to do the really power user stuff and I also see the need for a
application->package tool, but I have to admit I'm not sure on what the
latter should look like, or if it should be part of PackageKit core at
all.

Richard.