Open asdf8dfafjk opened 1 year ago
$ nix-instantiate --eval -A okular.outPath '<nixpkgs>'
"/nix/store/6c0h3b3a3p8qnhjipmxjfygsdqr027i8-okular-22.08.3"
$ nix-store -qR /nix/store/6c0h3b3a3p8qnhjipmxjfygsdqr027i8-okular-22.08.3 | grep mbrola
/nix/store/cfzmf36asbcjiq5h4pn4fznzk6rqc4gn-mbrola-3.3
$ nix why-depends /nix/store/6c0h3b3a3p8qnhjipmxjfygsdqr027i8-okular-22.08.3 /nix/store/cfzmf36asbcjiq5h4pn4fznzk6rqc4gn-mbrola-3.3
/nix/store/6c0h3b3a3p8qnhjipmxjfygsdqr027i8-okular-22.08.3
└───/nix/store/fazbdx73b4w17sd0mvphdbpm7zci38nw-qtspeech-5.15.7
└───/nix/store/cl38aj8cxhfjjraic8r4dks29gq0yqig-speech-dispatcher-0.11.2
└───/nix/store/cfzmf36asbcjiq5h4pn4fznzk6rqc4gn-mbrola-3.3
Would have to be made an optional dependency here:
I can suggest you to add an overlay disabling all heavy speech synthesizers backends, as I did for my config:
arcanPackages.espeak = super.arcanPackages.espeak.override { mbrolaSupport = false; pcaudiolibSupport = false; sonicSupport = false; };
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
It's also pulled by GNOME parts, including the ISO. Or at least it was, recently: https://github.com/NixOS/nixpkgs/issues/159612
I agree that such huge speech synthesizers should not be contained in defaults (of DEs, ISOs, and other packages except those very focused on speech synthesis)
(Sorry, miss click)
Same with kmail. mbrola needs to be explicitly enabled, it's too big :-(
I am not sure if this is actually worth it unless we also drop mbrola from chromium. I had an overlay for this locally before but there is not point in having it when I need to compile chromium.
I think it may be time to just disable it by default. That will suck for users of speech synthesis but we can't have everyone suffer >600MB in their closure for a select few.
A few questions before we do that:
Does our speech synth even work?
Why does the data need to be compiled into the respective apps?
Could they not look for data via env vars instead?
Alright, I had a quick look at what we're doing at it seems we hard-code the output path of the voices into espeak-ng.
What we should instead be doing IMO is:
/run/current-system/sw/share
(NixOS compat) and then in /usr/share
(non-NixOS compat) instead of hard-coding mbrola-dataWhy don't we patch espeak-ng to use /run/current-system/sw/share
in https://github.com/espeak-ng/espeak-ng/blob/master/src/libespeak-ng/synth_mbrola.c#L93 ?
@dotlambda we're currently patching it to use /nix/store/...-mbrola/share
.
Doing that instead (and perhaps also /usr for non-NixOS people) is what I meant with step 1.
- Patch the espeak-ng discovery algorithm to look for data in
/run/current-system/sw/share
(NixOS compat) and then in/usr/share
(non-NixOS compat) instead of hard-coding mbrola-data
$XDG_DATA_DIRS
and $NIX_PROFILES/share
may be better choices. That's exactly what we are doing with aspell dictionaries.
This should be an optional dependcy