The zoom-us package can be build with pulseaudio and with
support for one or more xdg-desktop-portal implementations.
This new module sets the proper build options
from the system configuration,
and adds the resulting package to `systemPackages`.
If an individual `zoom-us` package is assigned to the
`package` option with `package = zoom-us.override { ... };`,
arguments given to `.override` will take precedence
over the options determined by the module.
This permits to explicitly enable or disable some zoom-us
features while keeping the module's choices for other features.
Co-authored-by: Philip Taron <philip.taron@gmail.com>
To reduce the closure size of the zoom-us package,
this commit replaces the `xdgDesktopPortalSupport`
option with several new options that permit to (de-)select
several XDG desktop portal packages to be used by `zoom-us`.
Furthermore, two new options permit to inject further packages
(e.g. individual XDG desktop portal packages) into the virtual
filesystem that will be prepared by bubblewrap for zoom-us:
* `targetPkgs` is a *function* that maps the `pkgs`
packages attrset to a list of packages.
* `targetPkgsFixed` is a simple list of packages.
`targetPkgs` should be preferred before
`targetPkgsFixed` if possible, as the `buildFHSEnv`
mechanism expects a function as explained above:
It needs to extract a list of dependency
packages for a `pkgs` package attrset.
Package injection likely also works if `targetPkgsFixed`
is used, but that creates a liability
in that changes of the `buildFHSEnv` implementation might
(at least more likely) break zoom-us in unexpected ways.
Note: This now *disables* all
XDG desktop portal packages by default.
Co-authored-by: Philip Taron <philip.taron@gmail.com>
I believe this change is wrong both theoretically and practically.
Theoretically, `null` is available on every platform, because
`buildInputs = [ null ];` always succeeds and never throws a platform
availability error. `null` should be handled consistently with packages
that have no explicit list of supported platforms, as it of course
has no such list itself.
Practically, we use `null` to represent libraries that are always
present on a platform and do not require a library (for instance,
because they are part of `libc` or the macOS SDK). This has been
used for a long time by `libintl` (on all non‐glibc platforms),
and is also now used by `libGL` and friends on Darwin. This change
broke the check SDL3 does for OpenGL availability on Darwin, causing
<https://github.com/NixOS/nixpkgs/issues/407056>, which had to be
worked around by <https://github.com/NixOS/nixpkgs/pull/409525>.
Both `libintl` and `libGL` should count as available on platforms
where their functionality is part of the standard build environment,
and a package that is completely unavailable and whose functionality
cannot be expected should not use `null`, as it should result in
errors if used in a dependency list on an unsupported platform.
I accept that overriding with `null` is often a useful way to disable
dependencies that don’t have explicit feature flags, but I do not
think that making it work better with feature flags conditioned on
availability is worth the inconsistency and problems caused by this
change. Packages can instead expose the relevant feature flags as
arguments that default to the `lib.meta.availableOn` check or, if they
want to keep an “override the dependency to `null`” interface,
insert an explicit `pkg != null && …` check.
Additionally, the pull request was merged over a week after all
breaking changes were restricted for the 25.05 release. I believe that
the potential problems of dealing with the effects of this change for
an entire release cycle – the first release cycle where `libGL` is
`null` on Darwin, a change I made before the deadline and before this
change to `lib.meta.availableOn` – offset the risks of backporting
this revert at such a late stage.
It will cause overrides to backwards‐incompatibly revert to the
behaviour they had before the change, but since such overrides were
not possible until a few weeks ago, I hope that is an acceptable risk
compared to the potential issues leaving this in the release can
cause, given that it was merged after the deadline and has already
broken an existing construction in Nixpkgs.
This reverts commit 9338d924db.
