On Monday 17 October 2016, Jonathan Riddell wrote: > <apol> llucas`: on one hand, we need to figure out the dependency > system on KPackage, then we can look whether anything is needed on the > discover side, which shouldn't be needed > <llucas`> apol what about * store and dependencies: to both > plasma and other apps versions (for i.e. simplemenu, Dolphin service > menus) and to other store items (i.e. look&feel packages) and > integration with discover? > <alex-l_> About KDE Store: I noticed that i.e. Dolphin Service > Menus doesn't display KDE Store contents. The previous domains point > to store.kde.org now but the new contents on KDE Store are not aleays > displayed like in Dolphin > <Sho_> Riddell: I need basic version dependency handling - if I > put Simple Menu on the Store today, say, it won't work for anyone > because it needs 5.9 stuff
so, what i was thinking of doing is: having this managed mostly on the client side, kpackage supporting dependencies defined as appdata ids in its metadata file. (so would still need to download the apckage anyways) a key may be X-KDE-Depends=org.kde.plasmashell:5.9,org.someone.beautifulicons at first would try to install the thing with packagekit, if found, and that's probably the easy part (and where is i think realistic for 5.9) then the hard part is that it would need to search for stuff in the store as well. at that point, would be needed something in attica to search for a particular appstream id, that may take a long time unfortunately as may need a change in the server as well to add new api (i wouldn't like to have to specify dependencies as numerical ids?) -- Marco Martin
