This reverts commit 575b3a053a.
We don't know why ttuegel did it, and we suspect it was due to packages
breaking due to mixed qt5 versions used together, and not plasma itself
with qt5.15 - (#101369).
Part of (#101369): kdeApplications points to a set of derivations built
with a specific qt version, where libkcddb is available in libsForQt5's
callPackage scope, thanks to the parent commit of this commit.
Intro:
Part of #101369: Every attribute from kdeApplications and kdeFrameworks
can be built with a few different qt5 versions. It's hard to tell the
difference between an application and a library and some applications
rely on inputs from kdeApplications and libsForQt5 alike.
Before this change, some applications that were defined with
`libsForQt5.callPackage` used libraries from the kde* sets compiled with
a specific qt5 version,
Due to `inherit (kde*) <lib or app>;` used in the widest scope, we had
issues with packages that depended on packages defined by this
`inherit`. This led to mismatched qt versions used in the same inputs,
or the inputs of inputs etc.
Hence, we added to all libsForQt5* sets, packages that will be used from
the correct libsForQt5 set, in accordance to the
`libsForQt5*.callPackage` used. All `inherit (kdeApplications) <pkgs>`
and similar inheritance was moved out of all-packages.nix to aliases.nix
only for backwards compatibility.
Now some KDE applications show up in the attribute sets `libsForQt5*`
which didn't show up there previously. This is sort of misleading, as
these are not necessary libraries, but they show up in the wider scope
thanks to them in aliases.nix. Hence it's the best that can be done
considering the circumstances and the urgency of the issue.
Since it's a qt library, we can't guarantee every package using it as a
dependency will need it compiled with the same qt version, we put it in
all `libsForQt5*` scopes (#101369).
Part of #101369: In order to avoid packages using the default `kdesu`
always built with qt515, we put it in scope only for packages defined
with a `libsForQt5`, to avoid incompatible qt versions used together in
inputs of a package.
Make sure only compatible qt versions are used for it (#101369) -
kdeFrameworks is always using `libsForQt5` where e.g
`libsForQt514.kpmcore` would have otherwise used a kio compiled with
qt515.
Fixes#100707 - Since KDE's maintainers don't allow non official kde
applications under the `kdeApplications` path, many packages that depend
on KDE libraries and applications are defined in all-packages.nix.
Overriding all kdeApplications to use qt514 while all other
`libsForQt5.callPackage` in all-packages.nix are using qt515, causes
collisions.
When the stage-1 logs get imported in to the journal, they all get
loaded with the same timestamp. This makes it difficult to identify
what might be taking a long time in early boot.
