Review Request: Trigger installation of missing components when installing a package

[Kevin Kofler]

> 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.

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?


- 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
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20110811/585aa5de/attachment.html>