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?

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
> > <https://git.reviewboard.kde.org/r/129298/diff/1/?file=483567#file483567line436>
> >
> >     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
> 
>

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