In preparation for the deprecation of `stdenv.isX`.
These shorthands are not conducive to cross-compilation because they
hide the platforms.
Darwin might get cross-compilation for which the continued usage of `stdenv.isDarwin` will get in the way
One example of why this is bad and especially affects compiler packages
https://www.github.com/NixOS/nixpkgs/pull/343059
There are too many files to go through manually but a treewide should
get users thinking when they see a `hostPlatform.isX` in a place where it
doesn't make sense.
```
fd --type f "\.nix" | xargs sd --fixed-strings "stdenv.is" "stdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "stdenv'.is" "stdenv'.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "clangStdenv.is" "clangStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "gccStdenv.is" "gccStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "stdenvNoCC.is" "stdenvNoCC.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "inherit (stdenv) is" "inherit (stdenv.hostPlatform) is"
fd --type f "\.nix" | xargs sd --fixed-strings "buildStdenv.is" "buildStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "effectiveStdenv.is" "effectiveStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "originalStdenv.is" "originalStdenv.hostPlatform.is"
```
postgresql-libpq >= 0.10.2 invented a frankly bizarre way to discover
the libpq dependency of never actually declaring the dependency in any
cabal file, but instead discovering during configure whether it happens
to be installed anyways. Obviously this will require special
consideration from our side. (Probably we'll continue using pkg-config
which requires us to manually add pkg-config and libpq to the build
environment of postgresql-libpq-pkgconfig.)
Since Stackage LTS doesn't contain >= 0.10.2 yet, I'll ignore this for
now as I lack the patience at the moment.
These packages have been broken since before the 24.05 release. There
is a pull request open to update them to a newer OpenCV and get them
working again: <https://github.com/LumiGuide/haskell-opencv/pull/157>.
This package has been marked as broken for a year. If anyone wants to
fix it, there is a pull request updating it to the current FFmpeg API:
<https://github.com/acowley/ffmpeg-light/pull/72>.
Package version 2.1.5 failed to build and was therefore marked broken.
Package version 2.2 has fixed the twee-lib dependency version
constraint and can build successfully.
hnix 0.17.0 requires hnix-store-remote < 0.7 at the moment, so we'll
stay with this version until a new hnix version is released.
I noticed that there is something sort of wrong with hnix in nixpkgs. We
have a constraint from Stackage on hnix-store-core (and no other
package) which doesn't match the rest of the hnix packages as we need to
use hnix-store-core == 0.6.*. It may be prudent to check why this
constraint is in Stackage and whether we can downgrade to 0.6.*. It
seems to me that the store 0.8.* packages are not ready yet, i.e. no
support from hnix. hnix-store-core == 0.7.* seems to be a strange
version that hasn't really any other matching packages.
