-
-
Notifications
You must be signed in to change notification settings - Fork 13.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fontconfig: Stop using versioned config dirs #95358
Conversation
Let’s fix the chromium in master first: #95362 |
#95362 was merged, so master should be fixed. |
929199c
to
39e8025
Compare
I am completely convinced this is the way to go. |
# Don't try to write to /var/cache/fontconfig at install time. | ||
"fc_cachedir=$(TMPDIR)/dummy" | ||
"RUN_FC_CACHE_TEST=false" | ||
"sysconfdir=${placeholder "out"}/etc" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we need to set sysconfdir
for both install and configure?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, the configure makes /etc
hardcoded into the code but we cannot install to /etc
so we need to move the installation path into the derivation. It is quite common idiom.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay 👍
We might need to merge #95716 first (and then rebase this PR on top of master) |
@jtojnar can this be rebased? |
This reverts commit edf2541. Turns out lot of software (including Chromium) use bundled fontconfig so we either need to wrap every one of those, or re-introduce the global unversioned config. The latter is easier but weakens hermetic configs. But perhaps those are not really worth the effort. Given that programs linked against fc 2.12.6 on fc 2.13.92 system seem to at least display text, even while printing tons of errors (as long as you generate fc cache manually), and same thing the other way around, hopefully it will not be an issue in the future. We give up on the hermetic configs in exchange for getting rid of lot of complexity.
The incompatibility does not seem to exist any more: programs linked against fc 2.12 on fc 2.14 system seem to at least display text, even while printing tons of errors (as long as you generate fc cache manually), and same thing the other way around. Hopefully it will not be an issue in the future.
39e8025
to
b49a769
Compare
Rebased. |
@jtojnar I think we should document the fontconfig changes in the release notes eventually. |
Not convinced this is a good idea. What are we going to do when fontconfig changes in a backwards-incompatible way again in the future? |
The versioned config was introduced in 0927405 and c0e2ace (#4410) to resolve #2050, there were also some issues with Looking at the changes in #4410 (comment) it was really just minor relaxation of the schema. The unknown elements would already be skipped with a warning and the patch I sent upstream changes the unknown attributes severity to warning as well (and they were already ignored previously). For that reason backwards compatibility should not be an issue – the configs will continue to be parsed unless they change the format drastically, which is pretty unlikely with the upstream development pace. Forwards compatibility should not be an issue for the same reason. Outside of NixOS, we would use the unversioned config in either case so nothing changes there. |
The only other reason why we might still want to have versioning is to generate cache for multiple fontconfig versions declaratively but we are not really supporting multiple versions any way. And we could do that in a single config and fontconfig should ignore the cache files generated by other versions. |
The use of the argument was removed in 2016 but its definition was left behind. NixOS@cd2948a
Merging after IRC discussion with RM. |
I wanted to try some tests on latest nix build -f nixos/release-combined.nix nixos.tests.installer.swraid.x86_64-linux but got blocked by
You'll probably know way faster than me. |
--path $out/share/xml/fontconfig \ | ||
${./make-fonts-conf.xsl} $out/etc/fonts/fonts.conf \ | ||
> fonts.conf.tmp | ||
mv fonts.conf.tmp $out/etc/fonts/fonts.conf | ||
|
||
# Make it easier to remove user config in NixOS module. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@vcunat this probably should have been kept?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(or https://github.com/NixOS/nixpkgs/pull/95358/files#diff-376672cba12c87d4103e6134632e306fR203 remove the symlink in case cfg.includeUserConf
is false?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I forgot to revert also 8425726.
Should be fixed by f0cb5c6. |
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: |
Motivation for this change
Turns out lot of software (including Chromium) use bundled fontconfig so we either need to wrap every one of those, or re-introduce the global unversioned config. The latter is easier but weakens hermetic configs.
But perhaps those are not really worth the effort. Given that programs linked against fc 2.12.6 on fc 2.13.92 system seem to at least display text, even while printing tons of errors (as long as you generate fc cache manually), and same thing the other way around, hopefully it will not be an issue in the future. If we give up on the hermetic configs, we can get rid of lot of complexity (see the diff).
Links
Things done
sandbox
innix.conf
on non-NixOS linux)nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
./result/bin/
)nix path-info -S
before and after)