Review Request 129298: RFC: supporting dependencies on KPackage

[Marco Martin]

> On Oct. 31, 2016, 5:19 p.m., Marco Martin wrote:
> > autotests/data/testpackagesdep/metadata.json, line 14
> > <https://git.reviewboard.kde.org/r/129298/diff/1/?file=483564#file483564line14>
> >
> >     if kns ends up using ids, maybe the server should be specified as well, as the id would be server-dependent?
> 
> Aleix Pol Gonzalez wrote:
>     I'm not sure, either way we need changes in the KNS API, as the current search in place won't work. I'd prefer if we could use rdn-like notation on kns.
>     
>     I don't think it should be server-dependent. If anything, if the user changes the contents server, it might not find the component.
> 
> Dan Leinir Turthra Jensen wrote:
>     Hmm... a knsrc points to a providers file, which in turn can hold more than one provider. The providers in the provider file have an ID, so perhaps we can use that? So we'd end up with e.g. kns://colors.knsrc/api.kde-look.org/1159726 instead. While the api.... bit looks like a server address, it's just the ID as found in the providers file (and might be any string, technically), and so that would be enough (just) to uniquely identify the item as found on a provider which (like with the kde store) might have multiple "servers".

could a content be identified like org.joe.beautifulicontheme ?
then the server having some function to resolve org.joe.beautifulicontheme to its id like 137345


- Marco


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/129298/#review100442
-----------------------------------------------------------


On Oct. 31, 2016, 5:09 p.m., Aleix Pol Gonzalez wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/129298/
> -----------------------------------------------------------
> 
> (Updated Oct. 31, 2016, 5:09 p.m.)
> 
> 
> Review request for KDE Frameworks, Plasma, Dan Leinir Turthra Jensen, and Marco Martin.
> 
> 
> Repository: kpackage
> 
> 
> Description
> -------
> 
> Makes it possible to specify components to be installed together with a KPackage. They will be specified by a url, we'll have handlers for any kind, making reasonably extensible and doesn't tie us to a technology.
> 
> In this repository I created two Proof of Concept of such handlers, one for the appstream urls and one for KNS: kde:scratch/apol/kpackage-install-helpers
> 
> 
> Diffs
> -----
> 
>   autotests/CMakeLists.txt 395b16e 
>   autotests/data/testpackagesdep/contents/ui/main.qml PRE-CREATION 
>   autotests/data/testpackagesdep/metadata.json PRE-CREATION 
>   autotests/data/testpackagesdep/testpackagesdep.testappdataxml PRE-CREATION 
>   src/kpackage/config-package.h.cmake 61f2f0c 
>   src/kpackage/private/packagejobthread.cpp 0a0cc01 
>   src/kpackage/private/packagejobthread_p.h 1babf0b 
> 
> Diff: https://git.reviewboard.kde.org/r/129298/diff/
> 
> 
> Testing
> -------
> 
> None. just builds. It's a proof of concept, not even the test I added was tested, it was just to display what it could look like.
> 
> 
> Thanks,
> 
> Aleix Pol Gonzalez
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20161101/8e086817/attachment-0001.html>