[packagekit] PackageKitExtra - package abstraction

[Richard Hughes]

On Mon, 2008-02-18 at 12:09 +0100, Sebastian Heinlein wrote:
> I plan to add an application to view to update-manager in the near
> future.

Well, could this not just be a client side filter? i.e.
gnome-packagekit, gnome-packagekit-devel, gnome-packagekit-dbg just gets
filtered to gnome-packagekit. The issue here is most packages that are
updated are shared, e.g. aspell, and hence have no application to tie
them to.

> To achive this all .desktop files are extracted from the archive and
> stored in a cache with some extra information. Currently all desktop
> files are shiped in the app-install-data package so that the cache can
> be rebuild afterwards again.
> 
> Here is the list of extra attributes that we use:
> 
> * X-AppInstall-Package
> Name of the corresonding package

Sure.

> * X-AppInstall-Popcon
> Integer that gives an idea how popular an application is. Calculated
> from user statistics.

>From where? I figured we could use the mugshot stats for this.

> * X-AppInstall-Section
> The section of the Ubuntu repository that the application is in. If not
> enabled we enable the section before installing the application.

We can get this info from PK.

> * X-AppInstall-Architectures
> The architectures which are supported by the package

Is this important?

> * X-AppInstall-Proprietary
> Does it contain non-free code?

Surely a licence would be a better field? Then the daemon can decide
what is free and what isn't.

> * X-AppInstall-Supported
> Is it supported by Canonical?
> 
> * X-AppInstall-Channel
> Label of a third party repository that contains the package of the
> application and needs to be enabled before.

You mean installing an application install can enable and then disable a
repository? Isn't this a security risk?

> * X-AppInstall-Codecs
> List of codes that are supported by the application. There are some
> manual created applications for codec packages.

A list of mime/types?

> * X-AppInstall-PatentBadness
> Possibly problematic code inside.

Surely Proprietary == PatentBadness from a user's point of view?

> If you type in a not installed command into your terminal, Ubuntu
> currently looks in to a command cache and presents packages that provide
> this command:
> 
> renate at laptop:~$ ncftp ftp.ubuntu.com
> The program 'ncftp' can be found in the following packages:
>  * ncftp
>  * ncftp2
> Try: sudo apt-get install <selected package>
> bash: ncftp: command not found

This is very cool for new users and something that I've sorely wanted in
Fedora for new users. How do you generate the binary->package table and
keep it updated?

This is something else that I think belongs in a table in extra-data.db
(see below) - and then a client access method added such like:

char **pk_extra_get_applications_for_binary ("ncftp")

On top of this it is trivial to build an executable like
pk-command-not-found which does the prompting for installation (rather
than telling the user what to do) as we can now install as non-root.

How do you wire this into bash for a command to be run when not found?
Is it pretty invasive?

> @Richard:
> 
> Do you already have got some rough ideas about PkExtra?

There's quite some demo code already present for PkExtra. If you
checkout git you'll find libpackagekit/pk-extra.c and
libpackagekit/pk-extra-obj.c

PkExtra is designed as a singleton to access the information in the
sqlite database from client programs. PkExtraObj is designed as a
instance object to cache a package_id and to "refine" it with details
from PkExtra. The idea being that client programs get the standard
non-localised data from the daemon, which they can then "enrich" with
data from PkExtra in a PkExtraObj object.

The PkExtra data is stored in a sqlite database located
in /var/lib/PackageKit/extra-data.db. There are currently two tables,
one for localised data like summary, and one for non-localised data such
as icon filename and executable name. The database is writable by root
and queryable by all users. The locales are encoded in the table
also.   

The client tools such as client/pk-import-desktop and
client/pk-import-specspo take data from different sources and insert
this into the extra-data.db database. The desktop parser collects all
the information it needs from the installed .desktop files by default,
although you can trivially use a different source
(--desktop-location=/usr/share/offline-desktop-files) if you want to
pre-seed the data from cached .desktop files. This is what I want to
push fedora to do.

I think the best way forward is for mime types would be a new table in
the database (or just add it to the data table), and some pretty client
access methods, sort-of like:

char **pk_extra_get_applications_for_mimetype ("text/c-src")

The ubuntu offline *.desktop store could be trivially added either on
package build time or at RefreshCache time. The former is probably best
if the database is pretty constant.

Does this align to what you think should happen?

Richard.