Review Request 129298: RFC: supporting dependencies on KPackage

Thu Nov 17 12:04:46 UTC 2016

> 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?
> 
> 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
> > <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).
> 
> 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, 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/20161117/fbda6ee6/attachment-0001.html>