Archive for August, 2011

Plasma/RPM/PackageKit GSoC work now in Rawhide

My GSoC 2011 work has now fully entered Rawhide, i.e. what will eventually become Fedora 17 and later.

The PackageKit portions of the work have already been in Rawhide for a while:

I have just imported the remaining portions of the work into Rawhide:

  • kde-settings-4.7-4.fc17 includes the RPM dependency generators.
  • I have rebuilt kdelibs, kdebase-runtime, kdebase-workspace and kdeplasma-addons to pick up the new Provides. Other packages will automatically pick up Provides and script engine Requires the next time they are rebuilt. (For data engine Requires, you will want to run the new plasma-dataengine-depextractor in kdelibs-devel during the build process, unless/until the upstream metadata.desktop includes an X-Plasma-RequiredDataEngines entry.)
  • kdelibs-4.7.0-3.fc17 includes all the libplasma portions of my GSoC project (as backported patches).

The new features should now be fully testable in Rawhide.

Update: I built kde-settings-4.7-5.fc17, which fixes showstopper bug #732271. (I also fixed a related issue in libplasma in kdelibs-4.7.0-4.fc17, but that fix should not be strictly required because the only thing I use Plasma::PackageMetadata::serviceType() for is to figure out the precise type of script engine to verify the presence of, and if I don’t have a service type, I just conservatively look for any script engine for the language, which should be fine as they tend to be packaged together anyway.)


Plasma + PackageKit: The last piece of the puzzle

I have just submitted a patch which implement automatic scanning of the source code of Plasma-related packages (e.g. widgets) for required data engines.

For packages in scripting languages and distributed through Open Collaboration Services (OCS), this is fully automatic and triggered from Package::installPackage. If an X-Plasma-RequiredDataEngines entry is present in the .desktop file (even if empty), the dependency extraction is not run and the explicitly provided information is trusted instead.

For native distribution packages, my patch adds a tool called plasma-dataengine-depextractor which can be run at any time during the build process and which adds the dependency information (the X-Plasma-RequiredDataEngines entry) to the relevant .desktop file.

Authors of plasmoids are encouraged to run plasma-dataengine-depextractor and/or fill in X-Plasma-RequiredDataEngines manually. (Please note that the list is expected to be comma-separated.)

Of course, the automatic scanning is not perfect; in particular, it will not detect convoluted ways to load data engines (e.g. if the name is a variable), and it may have false positives in some corner cases (commented-out use of a data engine, some other function called dataEngine and taking a string literal). However, I expect it to work well in practice, and if it doesn’t work, there’s always the possibility to explicitly add the X-Plasma-RequiredDataEngines entry.

This is the final portion of my GSoC 2011 project, so the project can now be considered 100% complete.

Leave a comment

It works: Plasma now looks up missing components through PackageKit!

Sorry, I haven’t blogged for a while, but rest assured that I’m still alive and coding. 🙂 I passed the midterm evaluation, and the final evaluation is approaching. So what do we have in the store?

  • My patches to PackageKit, Apper and gnome-packagekit got pushed upstream. The changes to the PackageKit core even trickled down all the way to Fedora 15 (and of course Fedora 16 and Rawhide). I have backported the Apper changes to the Rawhide kpackagekit package.
  • I added support for Plasma to automatically prompt for the installation of missing script and data engines the first time something attempts to use them. This patch got pushed upstream.
  • I submitted another patch for review, which makes Plasma request the installation of required script engines (always, as this is covered by existing metadata) and data engines (if specified in the metadata through a new X-Plasma-RequiredDataEngines entry) as soon as a package (usually a widget) is installed through Open Collaboration Services (OCS), rather than only when the user attempts to add the widget to some containment (desktop, panel etc.). This patch is pending upstream feedback.
  • I also wrote an RPM auto-Requires script based on the same metadata as the above patch. This ensures script and data engine dependencies will be automatically detected in future Fedora packages.

Now the only remaining work item on my project plan is automatic scanning for required data engines. (Script engines are already completely handled by the above patches.)

1 Comment