texlive: Retain updmap.cfg #58220
texlive: Retain updmap.cfg #58220
Conversation
|
@veprbl FYI :) |
|
@clefru Did you investigate what this updmap invocation does |
|
@veprbl would you be interested in adding this TeX label to https://github.com/NixOS/ofborg/blob/released/config.public.json#L94 ? |
Good catch, and interesting case: With updmap.cfg remove we got this during the build: As there are no updmap.cfg files read, this is a no-op, and no changes are written. With updmap NOT removed, so after this commit, we get this: As you can see the default answer is N, so this does nothing again. In my private postBuild hacks, I do to get this to work. However, now we are really starting to affect the texlive derivation output by much more than just a file. We are moving updmap.cfg to a different location, namely texmf-config, and all map files are potentially updated now. I do think that this is good and correct behaviour. However, I am not an expert. |
…-config. As discussed in NixOS#58026 (comment)
|
I updated the PR to add "echo y" for "updmap --syncwithtrees", so that it actually does something. See above. |
|
Friendly ping for merge |
|
Sorry for delay. I have some questions about effects of this change. I'm wondering if this updmap.cfg that comes with My understanding is that regenerating maps doesn't really help anything you do. If we wanted to keep things simple, we would just drop that "updmap" call. |
|
I am not sure what you mean "pre-generated maps" that we ship. If you use texLive.combine { then you might get a different updmap in your derivation depending on the fonts you put into your package selection. So there isn't really a "standard", other than maybe the standard derivations that we provide with texlive.scheme-{minimal|basic|medium|tetex|....}. Also I looked at the updmap.cfg in the texlive.tetex.pkgs derivation and it's pretty complete. Is there something special about this updmap.cfg? I could look into all updmap.cfg that might exist in all the tex packages (around 8000), but that rests on the hypothesis that "updmap.cfg --syncwithtrees" does the wrong thing somehow with one of those updmap.cfg. I do believe that updmap.cfg --syncwithtrees always is the right thing. |
|
I am not that good at mentally reloading the context of this PR with long pauses in between comments. Can we move this faster? |
There was a problem hiding this comment.
This appears to be an valid change. "updmap −−syncwithtrees" filters the existing updmap.cfg to disable unavailable maps, it seems to work as expected. No maps are regenerated by doing this, so, in principle, this affects nothing for almost all of the users. This should enable users to blindly do "updmap --user" which seem to have a potential to cause some problems for them down the line. I was thinking about instead keeping "rm updmap.cfg" and additionally completely dropping "updmap --sys --syncwithtrees" call so that texlive.combine gets slightly more simplified.
Motivation for this change
As discussed in
#58026 (comment)
Things done
Ran pdflatex on a standard document.
Also I retain a private override which saves updmap.cfg before its deletion, and I have been running this for quite some time now, using pdflatex and xetex. I haven't noticed anything wrong with my setup by the presence of updmap.cfg and as this is part of the standard texlive distribution, I can't imagine this to be a problem.
sandboxinnix.confon non-NixOS)nix-shell -p nix-review --run "nix-review wip"./result/bin/)nix path-info -Sbefore and after)