Re: Self-introduction: GSoC student (Fedora Project) working on Plasma PackageKit integration
On Sunday 19 June 2011 14:57:38 Kevin Kofler wrote: > Thomas Olsen wrote: > > This sounds great. Last year I wanted to make something like this myself > > [1] only just for scripted DataEngines via OCS, but due to personal > > circumstancies I was unable to procede with the project. > > To support fetching dependencies from OCS, we will need not only a way to > handle dependencies (which I'm working on), but also some way to know what > OCS entry provides the data engine "foo". For distribution packages, > PackageKit can do the lookup for us (with minor changes which I can base on > already existing code), but for OCS packages, we probably also need some > work done on the OCS side. Doesn't OCS packages have a unique ID? From the to of my head I was thinking of something like: X-KDE-PluginInfo-Depends-OCS-Package=XXX > We'd also have to try both OCS and PackageKit if > we don't know where a dependency can be found. -- Best regards / med venlig hilsen Thomas Olsen ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Self-introduction: GSoC student (Fedora Project) working on Plasma PackageKit integration
Thomas Olsen wrote: > This sounds great. Last year I wanted to make something like this myself > [1] only just for scripted DataEngines via OCS, but due to personal > circumstancies I was unable to procede with the project. To support fetching dependencies from OCS, we will need not only a way to handle dependencies (which I'm working on), but also some way to know what OCS entry provides the data engine "foo". For distribution packages, PackageKit can do the lookup for us (with minor changes which I can base on already existing code), but for OCS packages, we probably also need some work done on the OCS side. We'd also have to try both OCS and PackageKit if we don't know where a dependency can be found. Kevin Kofler ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Self-introduction: GSoC student (Fedora Project) working on Plasma PackageKit integration
On Tuesday 14 June 2011 08:42:17 Kevin Kofler wrote: > This summer, I am working on a Google Summer of Code 2011 project with the > Fedora Project, mentored by Rex Dieter. The main goal of my project is to > enable Plasma to install required script engines and data engines for > Plasma widgets downloaded through Open Collaboration Services (OCS) > through PackageKit. (The script engines and data engines cannot be offered > through OCS because they have to be compiled for the distribution.) Rex > Dieter has been suggesting to use PackageKit for this purpose for a while: > http://rdieter.livejournal.com/14707.html > http://rdieter.livejournal.com/14897.html This sounds great. Last year I wanted to make something like this myself [1] only just for scripted DataEngines via OCS, but due to personal circumstancies I was unable to procede with the project. [1] http://mail.kde.org/pipermail/plasma-devel/2010-December/thread.html#14411 -- Best regards / med venlig hilsen Thomas Olsen ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Self-introduction: GSoC student (Fedora Project) working on Plasma PackageKit integration
Hi, let me briefly introduce myself: I am Kevin Kofler, I'll be 28 years old on July 1st, I'm studying for a PhD in Mathematics at the University of Vienna, Austria, and I'm an Italian citizen. I am a Fedora KDE packager and a KDE developer. This summer, I am working on a Google Summer of Code 2011 project with the Fedora Project, mentored by Rex Dieter. The main goal of my project is to enable Plasma to install required script engines and data engines for Plasma widgets downloaded through Open Collaboration Services (OCS) through PackageKit. (The script engines and data engines cannot be offered through OCS because they have to be compiled for the distribution.) Rex Dieter has been suggesting to use PackageKit for this purpose for a while: http://rdieter.livejournal.com/14707.html http://rdieter.livejournal.com/14897.html and his idea has been received positively by Plasma developers, so I am hoping for a successful cooperation with the Plasma project. (A positive side effect will be that Plasma-related dependencies between distribution packages can also be automatically generated.) On the PackageKit side, not much is needed, however we will need a new method in the org.freedesktop.PackageKit.Modify interface, similar to the existing InstallFontconfigResources, InstallGStreamerResources or InstallPrinterDrivers APIs. This is my next task in my project plan and will be required to implement the Plasma-side code, which is why I'm cross-posting this mail to the PackageKit list. Of course, some support for this feature is also needed on the package manager level. I am implementing automatic extraction of Provides and Requires for RPM. While I do not plan to work on other package managers myself at this time, I expect it to be relatively easy to add support for other packaging systems once the Plasma and PackageKit code is in place. I will be available for questions and guidance to anyone working on supporting this feature for other package managers. The plan for how I intend to implement the features can be found at: http://www.google-melange.com/gsoc/project/google/gsoc2011/kevinkofler/7001 I hope this makes sense to you (it definitely does make sense to Rex and me, but we aren't Plasma or PackageKit developers), otherwise please provide constructive feedback. Expect patches to be trickling in soon. So far, we have support for extracting RPM Provides information from Plasma .desktop file metadata: https://kevinkofler.wordpress.com/2011/06/05/automatic-plasma-rpm-provides/ The naming scheme plasma4(servicetype-name) was modeled after the GStreamer Provides, which are used in a similar way as these Plasma Provides will be used (automatic installation through PackageKit) and which use a gstreamer0.10(servicetype-mimetype) naming scheme. Here too, I hope this naming scheme makes sense to you, otherwise please speak up now, before we start generating these Provides in Fedora Rawhide packages. Similarly to how this works for GStreamer, I intend to use the same naming scheme in the org.freedesktop.PackageKit.Modify API, but as for GStreamer, backends can map this to whatever the underlying packaging system requires. I am looking forward to a productive summer working with the Plasma and PackageKit projects. Kevin Kofler ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel