From Fedora Project Wiki

< Features

Revision as of 04:27, 3 December 2011 by Kkofler (talk | contribs) (Create feature page (still incomplete).)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

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

Scope

The feature can be split into 2 parts:

  1. Dependency extraction
  2. PackageKit integration

Dependency extraction can again be split into 2 parts:

  1. 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.
  2. 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

User Experience

Dependencies

Contingency Plan

Documentation

Release Notes

Comments and Discussion