Re: Review Request 129298: RFC: supporting dependencies on KPackage

2016-11-17 Thread Aleix Pol Gonzalez


> On Oct. 31, 2016, 6:19 p.m., Marco Martin wrote:
> > src/kpackage/private/packagejobthread.cpp, line 436
> > 
> >
> > would this need a local database of installed packages/dependencies?
> 
> Aleix Pol Gonzalez wrote:
> No. I don't want a KPackage db. Both the distro and KNS have some of this 
> stuff in place.
> That said, I'm not sure how I expect it to work, some research there 
> would be welcome.

Let's assume this is not a problem for now. Worst-case scenario, the user can 
uninstall these anyway.


> On Oct. 31, 2016, 6:19 p.m., Marco Martin wrote:
> > autotests/data/testpackagesdep/metadata.json, line 14
> > 
> >
> > 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).
> 
> Aleix Pol Gonzalez wrote:
> 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.
> 
> Marco Martin wrote:
> so, if the dependency is a library and whatnot (qtcurve style comes to 
> mind) the dependency would be an appstream id, otherwise 
> ocs://providerId/contentId

For now, let's use KNS for dependencies, Attica/OCS doesn't have a database of 
installed resources or even a way to know how to install a package or whether 
it's installed.

If the user changes his provider and the provider doesn't have the package, 
then tough luck for him.
Same goes with the packagekit case, if the user changes his repositories to 
something that doesn't have what the user needs, then he'll have to refrain 
from installing the package in the first place.


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

Re: Review Request 129298: RFC: supporting dependencies on KPackage

2016-11-17 Thread Marco Martin

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



now that even the kns refactor got in, can we continue on this? need help on 
this?

- Marco Martin


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



Re: Review Request 129298: RFC: supporting dependencies on KPackage

2016-11-04 Thread Marco Martin


> On Oct. 31, 2016, 5:19 p.m., Marco Martin wrote:
> > autotests/data/testpackagesdep/metadata.json, line 14
> > 
> >
> > 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).
> 
> Aleix Pol Gonzalez wrote:
> 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.

so, if the dependency is a library and whatnot (qtcurve style comes to mind) 
the dependency would be an appstream id, otherwise ocs://providerId/contentId


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



Re: Review Request 129298: RFC: supporting dependencies on KPackage

2016-11-02 Thread Aleix Pol Gonzalez


> On Oct. 31, 2016, 6:19 p.m., Marco Martin wrote:
> > autotests/data/testpackagesdep/metadata.json, line 14
> > 
> >
> > 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
> 
>



Re: Review Request 129298: RFC: supporting dependencies on KPackage

2016-11-01 Thread Dan Leinir Turthra Jensen


> On Oct. 31, 2016, 5:19 p.m., Marco Martin wrote:
> > autotests/data/testpackagesdep/metadata.json, line 14
> > 
> >
> > 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

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


- Dan Leinir Turthra


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



Re: Review Request 129298: RFC: supporting dependencies on KPackage

2016-11-01 Thread Marco Martin


> On Oct. 31, 2016, 5:19 p.m., Marco Martin wrote:
> > autotests/data/testpackagesdep/metadata.json, line 14
> > 
> >
> > 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
> 
>



Re: Review Request 129298: RFC: supporting dependencies on KPackage

2016-11-01 Thread Dan Leinir Turthra Jensen


> On Oct. 31, 2016, 5:19 p.m., Marco Martin wrote:
> > autotests/data/testpackagesdep/metadata.json, line 14
> > 
> >
> > 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.

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


- Dan Leinir Turthra


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



Re: Review Request 129298: RFC: supporting dependencies on KPackage

2016-10-31 Thread Aleix Pol Gonzalez


> On Oct. 31, 2016, 6:19 p.m., Marco Martin wrote:
> > autotests/data/testpackagesdep/metadata.json, line 14
> > 
> >
> > if kns ends up using ids, maybe the server should be specified as well, 
> > as the id would be server-dependent?

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.


> On Oct. 31, 2016, 6:19 p.m., Marco Martin wrote:
> > src/kpackage/private/packagejobthread.cpp, line 436
> > 
> >
> > would this need a local database of installed packages/dependencies?

No. I don't want a KPackage db. Both the distro and KNS have some of this stuff 
in place.
That said, I'm not sure how I expect it to work, some research there would be 
welcome.


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



Re: Review Request 129298: RFC: supporting dependencies on KPackage

2016-10-31 Thread Marco Martin

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



yep, that's pretty much what i had in mind.
it's early stage, but if someone doesn't have significant issues with it, i 
think is a good direction to go


autotests/data/testpackagesdep/metadata.json (line 14)


if kns ends up using ids, maybe the server should be specified as well, as 
the id would be server-dependent?



src/kpackage/private/packagejobthread.cpp (line 436)


would this need a local database of installed packages/dependencies?


- Marco Martin


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



Review Request 129298: RFC: supporting dependencies on KPackage

2016-10-31 Thread Aleix Pol Gonzalez

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

Review request for KDE Frameworks and Plasma.


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