User:Kkofler/GSoC 2011 Proposal
From FedoraProject
Contents
|
Title (as submitted)
KDE Plasma Dependency Generation and PackageKit Integration
Abstract (as submitted)
The goal of my proposal is to add automatically-generated RPM dependencies for services related to KDE Plasma (e.g. Plasma script engines, Plasma data engines), and to add PackageKit hooks to use them to Plasma. (Idea by Rex Dieter.)
Plasma widgets can be installed from distro packages or through OCS. They can depend on script or data engines. The need to be addressed is how to drag in those dependencies in an effective way. I will work on 1. dependency extraction and 2. PackageKit integration.
Proposal (as submitted)
Contact Information
Email Address: 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)
Telephone: [redacted]
Blog URL: http://kevinkofler.wordpress.com
Freenode IRC Nick: Kevin_Kofler
Why do you want to work with our team?
I have been using Fedora since Fedora Core 1, and Red Hat Linux before that. It has been my only operating system since Fedora Core 4. I started doing volunteer packaging in 2007, around the time of the Core-Extras Merge, mainly for the KDE SIG. I have been enjoying working on and with Fedora ever since.
Getting picked for GSoC would allow me to spend more time on actual coding benefitting Fedora, not just packaging.
Do you have any past involvement with our team or another open source project?
Yes, I am part of several FOSS projects, including Fedora (since 2007, see my user page and the previous paragraph), KDE (where I have been the upstream maintainer of Kompare since 2007) and, in the past, TIGCC, a cross-toolchain for TI calculators with m68k CPUs based on GCC (2001-2006, also developed the KDE-based IDE KTIGCC, sporadic commits from 2007 on). I also contributed patches to several other projects.
Why should we choose you over other applicants?
I have strong experience with KDE code from the above and other projects and I am known for completing even complex tasks successfully and on time. (For example, I implemented ConsoleKit support in KDM in time for Fedora 7 on a very short notice. A modified version of that code has been merged upstream into KDE 4.2, and several distributions had carried earlier versions as patches.) I am especially interested in distribution integration tasks, seeing different components of the proverbial jigsaw puzzle stitch together flawlessly makes me feel happy.
I also have strong experience with Fedora packaging and development, and I am used to working with Fedora in general, and the KDE SIG in particular.
In addition, my research contract at my university (I am a PhD student at the University of Vienna, Austria) expires in May, so I will have plenty of time to work on my GSoC project (full time).
Proposal Description
Overview
The goal of my proposal is to add automatically-generated RPM dependencies for services related to KDE Plasma (e.g. Plasma script engines, Plasma data engines), and to add PackageKit hooks to use them to Plasma.
The proposal is based on a Fedora GSoC idea by Rex Dieter (see also a blog post by him on the subject).
The original ideas by Rex Dieter have buyin from key upstream developers. Getting upstream buyin for my implementation will be an essential part of my project, and there may be some changes to the implementation details based on feedback from upstream Plasma developers.
Problem Space
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.
Experience
- Programming in various languages since childhood (10-20 years of experience)
- FOSS developer since 2001
- Studied Software and Information Engineering, a specialization of Computer Science, from 2001 to 2009, graduated with a Bakk.techn. (equivalent to a European Bachelor) in May 2009
- Some C/C++ programming projects as part of my Mathematics studies (2001-ongoing), graduated with a Mag.rer.nat. (equivalent to a European Master of Science) in November 2007, now working on a PhD
- Fedora developer and packager since 2007, Fedora sponsor and provenpackager since 2009, comaintainer of the affected packages (kdelibs, kdebase-workspace, kdeplasma-addons)
- KDE development experience:
- 2004-2006: KTIGCC, an IDE for the TIGCC cross-toolchain based on KDE 3 libraries (KatePart and others). Completed as a GSoC project, mentored by Detached Solutions, in 2006.
- Since 2006: Ongoing maintenance of KTIGCC, including a port to the KDE Platform 4 (currently in Alpha stage).
- 2006: Wrote the KDE 3 GUI for a team project in a Software Engineering course at the university, a tool to organize, archive and (semi-automatically) tag audio and video files.
- 2007: Rescued Kompare from bitrot by completing the port to the KDE Platform 4 in time for KDE 4.0.
- Since 2007: Maintainer of Kompare in kdesdk 4.
- Since 2007: Developer of patches to several KDE components as needed for Fedora (e.g. the KDM ConsoleKit patch for Fedora 7 upstreamed in 4.2).
Implementation
The proposal 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 goal is to have the output of the project included in the KDE Software Compilation 4.8.0 release and in Fedora 16 (backported, if and to the extent reasonably possible) or 17 (as part of 4.8.x).
Timeline
The following is my expected timeline for the project. Dates marked "(fixed)" are fixed by Google or Fedora.
- April 25 - May 23 (4 weeks): Getting started (Community Bonding Period)
- May 23 (fixed): Start of coding period
- May 23 - June 6 (2 weeks): Provides extraction
- June 6 - June 20 (2 weeks): Implement the required PackageKit interfaces for PackageKit integration
- June 20 - June 27 (1 week): Runtime downloading of dependencies
- June 27: First usable version of the work.
- June 27 - July 4 (1 week): Automatic downloading of explicitly-specified dependencies at download time
- July 4 - July 11 (1 week): Get explicit dependency specifications added to popular plasmoids
- July 11 (fixed): Mid-term evaluations
- July 11 - August 1 (3 weeks): Automatic dependency extraction
- End of July (fixed, exact date not yet known): Expected Fedora 16 feature freeze
- August 1 - August 15 (2 weeks): Slack time, potential to work on additional deliverables (e.g. DrKonqi PackageKit integration, see below)
- August 15 (fixed): Suggested "pencils down" date
- August 15 - August 22 (1 week): Final polishing
- August 22 (fixed): Firm "pencils down" date (end of coding period)
- Early September (fixed, exact date not yet known): Expected Fedora 16 "features 100% complete" deadline
Other Details
If time permits, some additional aspects of PackageKit integration with KDE can be considered. For example, it would be nice to have a debuginfo installation script for DrKonqi based on PackageKit and KPackageKit/Apper instead of the current solution invoking debuginfo-install in a Konsole; this will be implemented as an additional deliverable if time permits.
Have you communicated with a potential mentor? If so, who?
Yes, Rex Dieter has offered to mentor me.
Updates and Comments
This has now been implemented (see my blog) and was approved as a feature for Fedora 17.
