Review Request 129298: RFC: supporting dependencies on KPackage

[Aleix Pol Gonzalez]

> On Oct. 31, 2016, 6: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".
> 
> Marco Martin wrote:
>     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
> 
> Dan Leinir Turthra Jensen wrote:
>     ...what server? That is just another string ID (technically the number that you get in OCS is just a string, and at least one implementation (MidGard) uses that fact). i really don't see how we can get away with having anything less than two string IDs (server ID as defined in a providers.xml, and content ID as unique to that provider) to uniquely identify a content item... i also don't really see why it'd necessarily be better, in any real way other than aesthetics of the link, to have anything more concise than kns://knsrcfile/providerID/contentID (and possibly kns://providerID/contentID in cases of using the default provider as defined by kns internally, which resolves to using KDE's providers.xml).

I'll come up with a patch to search-by-id, I guess everything will look much more clear afterwards.
Nevertheless, I think it's clear that passing a providerID bypasses the provider abstraction.

If we want to make sure a specific package is installed, maybe it would make sense to add a 3rd plugin which is `http://` or even `ocs://` that assume the resource is a KPackage.


- Aleix


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


On Oct. 31, 2016, 6: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, 6: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/20161102/facb8934/attachment-0001.html>