KDE Plasma Dependency Generation and PackageKit Integration

Summary

Add automatically-generated RPM dependencies for services related to KDE Plasma (e.g. Plasma script engines, Plasma data engines) and PackageKit hooks to use them to Plasma.

Owner

Name: Kevin Kofler
Email: kevin DOT kofler AT chello DOT at (aliases: Kevin AT tigcc DOT ticalc DOT org, kkofler AT fedoraproject DOT org, kevin DOT kofler AT gmail DOT com)

Current status

Targeted release: Fedora 17
Last updated: 2011-12-03
Percentage of completion: 100%

All patches are already in Rawhide. Several of them have also been upstreamed to the relevant projects (but Fedora 17 is the first Fedora release where the feature is enabled and complete).

Detailed Description

Plasma widgets (also known as plasmoids) can be installed from 2 sources:

Fedora packages (or distribution packages in general): For plasmoids written in C++, this is the only alternative.
the Open Collaboration Services (OCS) API, which allows installing plasmoids written in scripting languages directly from upstream. (Plasma provides an OCS-based dialog to easily download and install plasmoids written in scripting languages.)

Such Plasmoids can depend on services provided by Plasma, in particular:

script engines: These engines add support for a scripting language to Plasma, and their packages also drag in the relevant interpreter through RPM dependencies. Currently supported (as of 4.6.1) are JavaScript, Python, Ruby, and Google Gadgets. A plasmoid written in a scripting language always requires the script engine it is written in.
data engines: These engines act as libraries providing some information to plasmoids. They can be used to bridge languages (e.g. a Python plasmoid can use a data engine written in C), share code or just provide a clean frontend (plasmoid) / backend (data engine) separation. For example, several weather plasmoids (some of them written in scripting languages) all share the weather data engine provided by kdeplasma-addons.
some other services, e.g. "weather ions" (plugins for the weather data engine)

The need to be addressed is how to drag in those dependencies in an effective way:

For Fedora packages, we would like to have the dependencies handled automatically by RPM instead of error-prone manual specification.
For plasmoids installed through OCS, the dependencies are currently not handled at all. For example, if the user wants to install a Ruby-based plasmoid without having the plasma-scriptengine-ruby package installed, he/she will just get a cryptic error message. (Making Ruby a hard dependency of kdebase-workspace would be highly impractical.) We would like packaged script or data engines required by the installed plasmoid to be automatically installed when the user downloads and installs the plasmoid.

Benefit to Fedora

Users will be able to install Plasma widgets (plasmoids) written in scripting languages through "Add widgets… / Download new widgets…" and automatically get the required Fedora packages for those widgets to actually work installed. This gives users convenient access to upstream's huge widget library without manually having to install dependencies such as plasma-scriptengine-*. (It is not possible to include all the script engines and the script interpreters they require on the live image and thus in the default installation.)

It looks like Fedora will be the first distribution to offer this convenient Plasma feature, developed by Fedora.

Scope

The feature can be split into 2 parts:

Dependency extraction
PackageKit integration

Dependency extraction can again be split into 2 parts:

Provides: This is the easier part because it is already well covered by metadata. The main goal there is to bring the information provided by the metadata into a form usable in RPM.
Requires: This is the harder part because the metadata provided by upstream does not currently include dependencies. Several strategies to handle this can and will be envisioned:
- Explicit specification, i.e. require the Plasma metadata to list dependencies explicitly. Pros: reliable, allows installing dependencies immediately. Cons: does not work for existing plasmoids, error-prone.
- Automatic extraction from the source code, similar to how the RPM dependency extractors for scripting languages work. Pros: allows installing dependencies immediately (build-time auto-extraction) or almost immediately (auto-extraction run on downloaded sources), works for existing plasmoids, no developer efforts. Cons: probably needs extra code for each scripting language, can be fooled by convoluted code (e.g. requesting a data engine in a non-obvious way).
- Runtime downloading, i.e. firing up KPackageKit/Apper (KPackageKit will be renamed to Apper as of the next upstream release) when a service which is not installed yet is requested. Pros: reliable, works for existing plasmoids, no developer efforts. Cons: dependencies can only be installed on first use, which is not the most user-friendly approach.
My plan is to try implementing all 3 approaches. It is likely that a combination of multiple approaches will be retained (e.g. use explicitly specified dependencies where available, try automatic extraction otherwise, fall back to runtime downloading if everything else fails).

For PackageKit integration, Plasma needs to be taught to request the installation of a dependency through a PackageKit interface (to be provided by KPackageKit/Apper; for Fedora, org.freedesktop.PackageKit.Modify.InstallPackageNames could probably be abused at first, but for cross-distribution compatibility, which is essential for getting the feature upstreamed, a dedicated API like the existing InstallFontconfigResources, InstallGStreamerResources or InstallPrinterDrivers APIs should be used):

For explicitly specified or automatically extracted dependencies, this should happen after downloading the metadata (or the entire plasmoid package, they're usually small anyway).
For runtime downloading, this needs to happen when the uninstalled service is requested by a plasmoid.

The feature was implemented as a Google Summer of Code 2011 project with Fedora (mentored by Rex Dieter).

How To Test

Install Fedora 17 KDE, or start the live CD. (No special hardware needed.)
Verify that plasma-scriptengine-python is NOT installed, or yum remove plasma-scriptengine-python.
Click on the "panel toolbox" icon (which looks like a cashew nut) at the right end of the panel.
Click "Add widgets…".
Click "Get new widgets… / Download new widgets".
Search for "Veromix" (a widget written in Python) and install it.
You should get prompted by Apper for installing the Python script engine.
Installing the Python script engine (through the Apper interface which comes up) should succeed.
Veromix should now be in the list of widgets which can be added to the panel through "Add widgets…". Add it.
You should see a working widget.

Of course, Veromix is just an example known to work. The same should work for almost all widgets available through that interface (though some might be incorrectly packaged by the upstream author). Any required script engines and/or data engines should get dragged in.

User Experience

Before

The user clicks on the panel "cashew".
The user clicks "Add widgets…".
The user clicks "Get new widgets… / Download new widgets".
The user searches for his/her favorite widget and installs it.
The widget now shows up in the list of widgets to add.
The user adds the widget to the panel.

The user ends up with a "broken widget" icon or a nonfunctional widget.

 ________________________ 
< HEY, WHAT'S THE BEEF?! >
 ------------------------ 
        \   ^__^
         \  (oo)\_______
            (__)\       )\/\
                ||----w |
                ||     ||

After

The user clicks on the panel "cashew".
The user clicks "Add widgets…".
The user clicks "Get new widgets… / Download new widgets".
The user searches for his/her favorite widget and installs it.

The user gets prompted by Apper to install the missing script and/or data engine(s).

 __________ 
< MIRACLE! >
 ---------- 
        \   ^__^
         \  (oo)\_______
            (__)\       )\/\
                ||----w |
                ||     ||

The user clicks "Yes" and enters the root password when prompted.
The widget now shows up in the list of widgets to add.
The user adds the widget to the panel.

The widget just works.

 ________ 
< BEEFY! >
 -------- 
        \   ^__^
         \  (oo)\_______
            (__)\       )\/\
                ||----w |
                ||     ||

Dependencies

PackageKit ≥ 0.6.16 – in Rawhide since July 4, 2011
Apper – in Rawhide since October 17, 2011 (and a KPackageKit build with the patch backported had been in Rawhide since August 1, 2011)
- or gnome-packagekit ≥ 3.1.3 for those who want to use that – in Rawhide since July 4, 2011
RPM dependency generators for Plasma – included in Rawhide's kde-settings since August 20, 2011
libplasma patches implementing the feature – included in Rawhide's kdelibs since August 20, 2011

Contingency Plan

The RPM dependency generators (or just the Requires part) can be dropped from kde-settings if they cause trouble.
The libplasma patches can be dropped from kdelibs if they cause trouble. (The PackageKit changes will have no effect without the libplasma part. In fact, due to having been merged upstream during the summer, they are already included in Fedora 16 without being noticed. ;-) )

Documentation

Release Notes

KDE Plasma's "download new widgets" feature now automatically prompts for installing the script engines and data engines required by the installed widget through Apper. (Plasma can also prompt for installing missing components at other times, but typically, the prompt happens when installing a widget.) This new feature, developed by Fedora, gives users convenient access to KDE's huge Plasma widget library without having to manually install dependencies such as plasma-scriptengine-*.

Comments and Discussion

See Talk:Features/YourFeatureName

Search

Features/Plasma PackageKit Integration

Contents