~Re: lookandfeel and dependencies (and potentially all kde-store related stuff)

[Aleix Pol]

On Thu, Oct 13, 2016 at 10:56 AM, Marco Martin <notmart at gmail.com> wrote:
> On Thu, Oct 13, 2016 at 1:19 AM, Aleix Pol <aleixpol at 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