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

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

Reply via email to