> On Aug. 11, 2011, 7:56 a.m., Aaron J. Seigo wrote: > > if i read this correctly, this means that the name of the package on the > > system needs to be the name of the dataengine. e.g. org.kde.foobar or > > whatever. is that going to be ok for packagers? > > > > also, this work needs to shift to being written against the frameworks > > branch, and then only after libplasma2 has been merged into it. note that > > in libplasma2, there is no PackageMetadata class and the install package > > routine has moved into PackageStructure as well.
> if i read this correctly, this means that the name of the package on the > system needs to be the name of the dataengine. e.g. org.kde.foobar or > whatever. That depends on how the PackageKit backend code is implemented. For RPM/Yum, we use virtual Provides of the plasma4(dataengine-org.kde.foobar) or plasma4(dataengine-foobar) (depending on what the data engine actually uses as its name) form. Looking up the correct package to provide a given data engine is PackageKit's job. > also, this work needs to shift to being written against the frameworks > branch, and then only after libplasma2 has been merged into it. note that > in libplasma2, there is no PackageMetadata class and the install package > routine has moved into PackageStructure as well. I can prepare a patch against libplasma2. I'm not sure I'll be able to test it at this time though. - Kevin ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/102291/#review5618 ----------------------------------------------------------- On Aug. 10, 2011, 10:10 p.m., Kevin Kofler wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/102291/ > ----------------------------------------------------------- > > (Updated Aug. 10, 2011, 10:10 p.m.) > > > Review request for Plasma. > > > Summary > ------- > > This is another part of my GSoC 2011 work. > > For script engines, the existing metadata (X-Plasma-API) is sufficient. > > For data engines, we introduce a new metadata entry: > X-Plasma-RequiredDataEngines. Third-party packages will have to add this entry > to benefit from this feature at this time. Automatic support for scanning > package source code on installation (at least for some languages) is planned, > but the metadata entry is definitely the most efficient method. > > > Diffs > ----- > > plasma/package.cpp 4c00d36 > plasma/packagemetadata.h b10f0e4 > plasma/packagemetadata.cpp 59163b2 > > Diff: http://git.reviewboard.kde.org/r/102291/diff > > > Testing > ------- > > Verified that it compiles without errors and that it successfully prompts for > a missing Python script engine right after installing a Python widget (I used > Veromix for my test) through KHNS (not only when actually using it) on Fedora > 15. Also verified that there is no such prompt if plasma-scriptengine-python > is already installed. > > (The patch is against master (4.8), but applies without changes to the > kdelibs 4.6.5 in Fedora 15, which is how I tested it.) > > > Thanks, > > Kevin > >
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
