> 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. > > Kevin Kofler 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. > > 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 Kofler wrote: > The libplasma2 branch doesn't even have my previous patch, on which this > is based, yet. Should I: > a) cherry-pick it? > b) attempt to merge master into libplasma2 (as has been done several > times before)? or > c) wait?
FWIW, I think we really need to do a kdelibs 4.8 release, if only for this work alone. This is an important improvement and shouldn't have to wait for 5.0. - 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
