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
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?