On Thu, Oct 13, 2016 at 10:56 AM, Marco Martin <notm...@gmail.com> wrote: > On Thu, Oct 13, 2016 at 1:19 AM, Aleix Pol <aleix...@kde.org> wrote: >>> What I dislike is that we're creating another package manager in the >>> ~/.local >>> directory. I do see a lot of advantages to allowing combinations of >>> packages, >>> and it would allow makers to not stupidly copy around sources, but work >>> together on whole themes / lnf / shells, etc.. >> >> I'm not sure you two are speaking the same language. Also I think >> there's 2 intertwined concepts. KPackage can depend on appstream >> components means that they can either come from: >> - the store, as every KPackage is also an appstream component (see >> kpackagetool5 --appstream-metainfo). >> - packagekit >> - potentially other sources offered by appstream (which in turn should >> be supported by kpackage) > > > > Ok, so let's make an example that looks concrete enough and see how > could be solved. > Let's say somebody uploads to the store a l&f package that provides a > different desktop layout, sets a different wallpaper and uses a > different icon theme. > > the wallpaper and the icon theme areavailable by themselves in the > store, so let's say the lnf theme is org.johndoe.desktopfeel the > wallpaper is org.franksmith.autumn and the icons are > org.besticoncreators.newicons (all the idems identifiable by a > reverse notation appstream friendly) > > knewstuff downloads org.johndoe.desktopefeel, looks in the metadata > file and sees the key > Dependencies=org.franksmith.autumn,org.besticoncreators.newicons > > > at this point, technically what happens? searching those names with > packagekit is an option (if things are available as packages may still > be preferable, especially if is like a qstyle or some other binary > based dependency, which is more likely to actually be provided by the > distro than a wallpaper) > > then, it should search on the store as well... this means attica/ocs > protocol should be extended with a query to search by reverse > notation? (and, the store should either force contnt publishers to > enter a name like that, or it could try to infer it somehow, like > combining author user name and user readable name of the content) > would that be feasible somehow?
I can try to put together a small patch that does this before the end of the month and we discuss over it, if you want. Aleix
