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.
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.
Update pkgs/tools/networking/bacnet-stack/default.nix
Co-authored-by: Daniel Løvbrøtte Olsen <daniel.olsen99+GitHub@gmail.com>
bacnet-stack: Add maintainer and use the original GitHub repo
bacnet-stack: Alphabetize
Update pkgs/top-level/all-packages.nix
Co-authored-by: Jon <jonringer@users.noreply.github.com>
Current nixpkgs always wraps neovim with the "-u" which has sideeffects as explained in https://github.com/NixOS/nixpkgs/issues/55376 :
1. vim won't set the variable $MYVIMRC as explained #34215
2. vim skips loading folder-specific .vimrc / .nvimrc
I wanted to provide a way for users to better control what flags are used to wrap neovim. This is achived by introducing wrapNeovimUnstable et neovimUtils, utilities to help with that. We provide a compatibility layer so that wrapNeovim still works and to let us experiment with wrapNeovimUnstable to better control neovim configuration, plugin dependencies, haskell environment etc so that it becomes easier to generate per-project neovim config.
With this commit, it's possible for instance for home-manager to wrap neovim without the `-u` and just write the config in the
expected $XDG_CONFIG_HOME/nvim/init.vim .
Expect wrapNeovimUnstable interface to evolve in the upcoming months.
This is a mostly cosmetical commit, in the sense it doesn't change the contents
of any package, but reorganizes the overall Nixpkgs expressions.
Terminal emulators are an ubiquitous tool for any Unix user; even the beginners
are routinely familiarized to it. And, manifestly, there are many
implementations of terminal emulators out there, from those traditionally made
in C and C++ to those written in Haskell and Go.
Terminal emulators deserve more highlight. This commit does that by creating a
category for them.
