Features/Plasma PackageKit Integration
(Create feature page (still incomplete).)
(→Benefit to Fedora: Fill in.)
|Line 34:||Line 34:|
== Benefit to Fedora ==
== Benefit to Fedora ==
--is to the
Fedora distribution this feature
== Scope ==
== Scope ==
Revision as of 04:35, 3 December 2011
KDE Plasma Dependency Generation and PackageKit Integration
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.
- 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)
- 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).
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:
- 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.
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.
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).