Hello Mr. Goebel,
To be really honest, I do not know much about KDE and all. I am just some random guy who knows a little bit of guix/guile/scheme/gnu/linux, and I just wanted to use Kdenlive, and really wanted a dark theme. (
https://issues.guix.gnu.org/43200)
I looked for the breeze icon theme in guix and found that we only had the breeze-icons package, and not the entire breeze theme, and adding that to kdenlive's dependencies did not supply the breeze theme in it's entirety. I looked around for a solution and bumped into this:
https://github.com/KDE/breeze-icons and this:
https://github.com/KDE/breeze
Seeing these two repos led me to conclude that the breeze-icons package merely supplied the icons, whereas the breeze repository held the entire breeze theme: what I was looking for in order to make the theme available in Kdenlive (this was the end goal).
So, I decided to package the contents of the breeze repo (
https://github.com/KDE/breeze) into a package, and (reluctantly) decided to call it breeze-assets. The reason that I inherited breeze-icons for this was because I thought that since they were both "basically the same" thing, or rather, parts of the same theme, they must share their dependencies. And I thought that since I don't know much about KDE, and setting up it's build environment, I started my packaging with: `guix environment breeze-icons && cd breeze # the breeze repo clone` and then went on adding more and more missing dependencies. Hence, the inheritance. So, it is not a well thought out decision on my part, but rather just what I started the whole thing with. I understand that this might be causing breeze-assets to have as inputs things that it does not require at all.
Once that was done, I tried adding breeze-icons and breeze-assets as dependencies for KdenLive but that was still not working correctly. At run time, some parts of the breeze theme were missing because the icons that should have been available in the Breeze Theme were not available as they were in separate /gnu/store/xxx-package directories. In order to resolve this issue, I had two choices: I could either declare breeze-assets and breeze-icons as propagated-inputs of kdenlive, or I could declare a union-build of breeze-assets and breeze-icons as a union build in the inputs of kdenlive itself. Being a (wannabe) guix/functional-package-management purist, I chose to go the second route. But then, I thought that perhaps other packages would also benefit from having the union of breeze-icons and breeze-assets readily available to just include in their input list. Hence, I added the union package: `breeze`. And with that added as an input for Kdenlive, and the runtime variable XDG_DATA_DIRS pointing to /gnu/store/xxx-breeze/share during runtime, kdenlive has the breeze theme available (Commit: e33a1e546a52aa70ffe0c8389f29ff3288cc4510).
Now, I can see that my solution is inelegant. And I should have not mixed two different things together. But because of my lack of knowledge regarding the matter, and my end goal of getting kdenlive's breeze theme working, it appears that I've implemented a kludge. Please do go ahead and make the corrective changes.
I have one request, however: that you please retain the union build of breeze-assets and breeze-icon as it makes it easier to get the entire theme without creating union-builds in every single package's input list. If that is acceptable to you (to keep the union build `breeze` package) - and please do correct me if I am wrong - am I correct in thinking that this must be a matter of only cleaning `breeze-assets` up (removing the inheritance, perhaps moving the package to another file altogether (kde-plasma.scm, perhaps) ?
If you do not have the time, and want me to clean this up, please do give me the instructions and I will be happy to make the necessary changes.
Again, please forgive me for the inconvenience caused.