these changes were generated with nixq 0.0.2, by running
nixq ">> lib.mdDoc[remove] Argument[keep]" --batchmode nixos/**.nix
nixq ">> mdDoc[remove] Argument[keep]" --batchmode nixos/**.nix
nixq ">> Inherit >> mdDoc[remove]" --batchmode nixos/**.nix
two mentions of the mdDoc function remain in nixos/, both of which
are inside of comments.
Since lib.mdDoc is already defined as just id, this commit is a no-op as
far as Nix (and the built manual) is concerned.
Portals are global so we can just link them globally.
There might, in theory, be some unexpected system-path contamination
(e.g. when a portal package installs its executables to `/bin`)
but I think the risk is relatively minor compared to the added complexity.
While at it, let’s point the environment variable to system-path.
That will allow changes to installed portals to apply without having to re-log in.
x-d-p only looks for portal definitions in one of two places:
- datadir (which we cannot install anything to, since Nix packages are immutable)
- when `XDG_DESKTOP_PORTAL_DIR` environment variable is set, the path specified therein
(meant for tests, disables looking for portal configuration anywhere else)
Let’s introduce our own `NIX_XDG_DESKTOP_PORTAL_DIR` environment variable
that will only control the portal definitions lookup.
We will not use it for searching for configuration
because it would require looking in the parent directory
and `XDG_CONFIG_DIRS` variable is sufficient for us.
conversions were done using https://github.com/pennae/nix-doc-munge
using (probably) rev f34e145 running
nix-doc-munge nixos/**/*.nix
nix-doc-munge --import nixos/**/*.nix
the tool ensures that only changes that could affect the generated
manual *but don't* are committed, other changes require manual review
and are discarded.
this renders the same in the manpage and a little more clearly in the
html manual. in the manpage there continues to be no distinction from
regular text, the html manual gets code-type markup (which was probably
the intention for most of these uses anyway).
make (almost) all links appear on only a single line, with no
unnecessary whitespace, using double quotes for attributes. this lets us
automatically convert them to markdown easily.
the few remaining links are extremely long link in a gnome module, we'll
come back to those at a later date.
the conversion procedure is simple:
- find all things that look like options, ie calls to either `mkOption`
or `lib.mkOption` that take an attrset. remember the attrset as the
option
- for all options, find a `description` attribute who's value is not a
call to `mdDoc` or `lib.mdDoc`
- textually convert the entire value of the attribute to MD with a few
simple regexes (the set from mdize-module.sh)
- if the change produced a change in the manual output, discard
- if the change kept the manual unchanged, add some text to the
description to make sure we've actually found an option. if the
manual changes this time, keep the converted description
this procedure converts 80% of nixos options to markdown. around 2000
options remain to be inspected, but most of those fail the "does not
change the manual output check": currently the MD conversion process
does not faithfully convert docbook tags like <code> and <package>, so
any option using such tags will not be converted at all.
It was never meant to be used for anything other than testing
and setting it globally can cause weird loops in GTK-based portals,
where the portal will end up waiting for itself until it times out.
https://github.com/NixOS/nixpkgs/issues/135898
Or it can mess up fonts:
https://github.com/NixOS/nixpkgs/issues/155291#issuecomment-1166199585
Having the option in NixOS makes it look like it is okay or even
desirable to enable, when in fact it is a hack that can subtly break apps.
Some apps allow opting into using portal-based APIs, e.g. for Firefox,
you can set `widget.use-xdg-desktop-portal.file-picker` to `1` in about:config.
Otherwise, you can set the `GTK_USE_PORTAL` environment variable to 1
for individual apps.
People who really want it and aware of the downsides can just set
`environment.sessionVariables.GTK_USE_PORTAL = "1";` NixOS option
directly to set the environment variable globally.
A centralized list for these renames is not good because:
- It breaks disabledModules for modules that have a rename defined
- Adding/removing renames for a module means having to find them in the
central file
- Merge conflicts due to multiple people editing the central file
If lib.optional is given a false value it will return an empty list.
Thusly the set-environment script can have
```
export GTK_USE_PORTAL=
```
This can rub certain bugs the wrong way #65679
so lets make sure this isn't set in the environment
at all.
Prior to this change GTK_USE_PORTAL was unconditionally
set to "1". For this to not break things you have to have some
sort of portal implementation in extraPortals.
Setting GTK_USE_PORTAL in this manner is actually only useful
when using portals for applications outside flatpak. For example
people using non-flatpak Firefox who want native filechoosers.
It's also WIP for electron applications to support this.
Left to do: re-enable as needed in the usual situations.
This added ~286MiB to the base system closure, which is enough to bring
the sd images over the limit allowed on Hydra.
Back in 2013, update-mime-database started using fdatasync() to write out
its changes after processing each file in /share/mime, with the reasoning
that a corrupted database from an interruption midway would be
problematic for applications[1]. Unfortunately, this caused a
significant regression in the time required to run update-mime-database:
commonly from under a second to half a minute or more.
This delay affects the time required to build system-path on NixOS, when
xdg.mime.enable is true (the default). For example, on one of my systems
system-path builds in ~48 seconds, 45 of which are update-mime-database.
This makes rapidly building new system configurations not fun.
This commit disables the calls to fdatasync(). update-mime-database
checks an environment variable, PKGSYSTEM_ENABLE_FSYNC, to determine
whether it should sync, and we can set this to false. system-path
already only has whatever filesystem commit guarantees that the Nix
builder provides. Furthermore, there is no risk of a failed MIME
database update messing up existing packages, because this is Nix.
(This issue was also reported at and discussed by Debian, Red Hat, and
Gentoo at least.)
[1] https://bugs.freedesktop.org/show_bug.cgi?id=70366
For update-mime-database to work, you must have to have some mime
packages installed. In some DEs like XFCE this is not guaranteed to
happen. In that case just skip the update-mime-database call.
Fixes#46162
