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

[Aleix Pol]

On Thu, Oct 13, 2016 at 1:10 AM, Sebastian Kügler <sebas at kde.org> wrote:
> Hey Marco,
>
> Sorry it took so long to give some feedback on this thread.
>
> On Wednesday, October 5, 2016 5:42:20 PM UTC Marco Martin wrote:
>> in plasma 5.8 a new option to download look and feel packages from the kde
>> store appeared.
>> since it's possible for a look and feel package to depend from external
>> stuff  (for instance, 3rd party icon theme and whatnot) how to manage that?
>>
>> I was thinking about kpackage metadata file containing a list of appstream-
>> compatible names for dependencies, then packagekit would figure out
>> dependency  packages to install.
>>
>> this will probably become an issue for plasmoids too and potentially a lot
>> of  content offered trough the KDE store.
>
> But packagekit won't go through the store, no? If it receives dependencies
> from the store and then install them through the package manager, you can't
> really pull in these packages from the store (since that' not what apt-get and
> friends are going to download and install from).
>
> Except if packagekit can tap into the store. My understanding is that it
> currently doesn't, but discover combines both sources in our ui.
>
>> would an approach like that make sense? any other ideas/opinions?
>
> At first, I thought it made total sense, but now I think I'm not understanding
> it. I think it could work if plasmapkg just tried downloading the additional
> packages, perhaps through attica (or something simpler).
>
> 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)

HTH,
Aleix