| Summary: | app-text/hunspell - add support for deactivating language variants | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Erik Quaeghebeur <gentoo> |
| Component: | Current packages | Assignee: | zurabid2016 |
| Status: | UNCONFIRMED --- | ||
| Severity: | enhancement | CC: | henning, kuraga333, maintainer-needed, proxy-maint, zurabid2016 |
| Priority: | Low | Keywords: | PullRequest |
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | All | ||
| URL: | https://github.com/gentoo/gentoo/pull/36552 | ||
| See Also: |
https://github.com/gentoo/gentoo/pull/36552 https://github.com/gentoo/gentoo/pull/38908 |
||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Erik Quaeghebeur
2013-08-19 10:33:36 UTC
(In reply to Erik Quaeghebeur from comment #0) > dictionary.lst.* [...] (I added # in lines of variants I did not want, but this > was not sufficient). This appears to be unnecessary, not touching the dictionary.lst.* files seems sufficient. (Tested in Thunderbird.) (In reply to Erik Quaeghebeur from comment #1) > (In reply to Erik Quaeghebeur from comment #0) > > dictionary.lst.* [...] (I added # in lines of variants I did not want, but this > > was not sufficient). > > This appears to be unnecessary, not touching the dictionary.lst.* files > seems sufficient. (Tested in Thunderbird.) spellchecker.dictionary_path;/usr/share/myspell you can just blank the pref in mozilla products and use external dicitionairies from mozilla if you so wish. (In reply to Jory A. Pratt from comment #2) > > spellchecker.dictionary_path;/usr/share/myspell > > you can just blank the pref in mozilla products and use external > dicitionairies from mozilla if you so wish. Good to know this, but I prefer to use the system spellchecker over using separate spellcheckers for every different application in which text is handled. *** This bug has been marked as a duplicate of bug 469422 *** (In reply to Ian Delaney from comment #4) > > *** This bug has been marked as a duplicate of bug 469422 *** Excuse me, in what way is this a duplicate of bug 469422? This bug is about language variants not being configurable; that bug is about man pages in all languages being installed! Please mark this bug as open again and remove me from the Cc list of the other, unrelated bug. Oh, sorry, I misread. I asked Ian to do that. I'm proxy-maintainer for the package now. Erik, The reason I had it marked duplicate is because it is similar to (but not the same as) bug 469422 - a cursory glance made me believe it was the same. Sorry about that. I've removed your CC accordingly. I am presently busy for the holidays and do not have time to fix this issue until mid-January. If anyone wishes to provide patches sooner, I'd happily look at them. (In reply to Erik Quaeghebeur from comment #0) > I see the following options: > 1. variant-use flags on the myspell packages to include/exclude them > (N.B.: variants don't always map to locales!) either by not installing them > or not installing the symlinks to /usr/share/hunspell (then the > English-language files should also be installed there) LINGUAS already exists as a variable; there is no need to add these USE flags, and would be redundant with LINGUAS anyway. > 2. a configuration script that finds the variants present and > installs/removes the necessary symlinks The list of files owned by the package would fall out of sync as a result, and a similar effect can be achieved by the end user if they're willing to let that happen. This also feels like a terrible bolted-on hack. > 3. upstream should take care of this, and this can be set by a system > config file in /etc and user config file in ~. Portage builds are not affected by system configuration other than portage variables as a matter of policy. Applications should respect your locale if it is showing all the language variants. How I would solve this issue (and I must emphasise I am very busy atm) is to simply check the LINGUAS variable. However, I am unsure of what to do when for instance, en is set but no variants are set (do we just install all variants?), or when both en and regional languages are set (do we install all variants or just the local one? that would be surprising behaviour if we install all variants with en). (In reply to Elizabeth Myers from comment #8) Dear Elizabeth, Thanks for looking at this bug. Take your time, there is a workable workaround. > > I see the following options: > > 1. variant-use flags on the myspell packages to include/exclude them > > (N.B.: variants don't always map to locales!) either by not installing them > > or not installing the symlinks to /usr/share/hunspell (then the > > English-language files should also be installed there) > > LINGUAS already exists as a variable; there is no need to add these USE > flags, and would be redundant with LINGUAS anyway. Well, I always assumed that LINGUAS was for the user interface language. This is in theory orthogonal to installed spellchecker languages (in practice there will usually be at least some overlap). So in principle I do think package-specific use flags would be proper and the current use of LINGUAS is improper. So, an important practical question is whether hunspell itself is localized. > How I would solve this issue (and I must emphasise I am very busy atm) is to > simply check the LINGUAS variable. However, I am unsure of what to do when > for instance, en is set but no variants are set (do we just install all > variants?), or when both en and regional languages are set (do we install > all variants or just the local one? that would be surprising behaviour if we > install all variants with en). (I'm ignoring my principled objection to this practically quite reasonable solution here.) I would interpret 'en' as 'en_*' (install all variants) and not do anything special when also a variant is set in LINGUAS. So 'en, en_US' would still result in 'en_*'. Picky people like me can always set and unset some linguas in /etc/portage/package.use for hunspell. Hello, I am a new hunspell maintainer (they do chage frequently, don't they?) Even though it's been 10 years since the issue has been opened, I agree that something should be done on this matter, especially regarding myspell-en. I am currently busy for a week or so, and once I have time I will work on adopting myspell-* packages together with making their flags sane. Both you and Elizabeth have expressed good ideas, so here is mine (for myspell-en): en LINGUAS flag is deleted and every other regional one is set on by default. This way we both get rid of ambiguity brought by general "en" flag, and don't "discriminate" anyone by setting only specific dialect by default (experienced users can always disable unneeded variants) What do you think? (In reply to zurabid2016 from comment #10) > en LINGUAS flag is deleted and every other regional one is set on by > default. This way we both get rid of ambiguity brought by general "en" flag, > and don't "discriminate" anyone by setting only specific dialect by default > (experienced users can always disable unneeded variants) > What do you think? I think the idea can definitely work. The only possible issue I see is that perhaps it should be L10N flags, not LINGUAS ones. I looked at the localization guide https://wiki.gentoo.org/wiki/Localization/Guide, but it didn't completely clarify the choice for me. Thank you for the "acknowledgement" :) Once I have wore free time, I will work on adopting the dictionaries themselves. As to distinction between L10N and LINGUAS, this will definitely be brought up on IRC and the best option will be implemented The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=dfe0f6835c24aa514c8f602fb5267c0f5c9aaa1a commit dfe0f6835c24aa514c8f602fb5267c0f5c9aaa1a Author: Zurab Kvachadze <zurabid2016@gmail.com> AuthorDate: 2024-05-04 21:25:49 +0000 Commit: Yixun Lan <dlan@gentoo.org> CommitDate: 2024-06-06 16:04:45 +0000 app-dicts/myspell-en: add 20240601, remove redundant l10n_en USE flag In the previous versions of app-dicts/myspell-en there was a IUSE=l10n_en, which unconditionally enabled all the English varieties. This USE flag is redundant, since the purpose it serves can be as easily achieved by switching the individual USE flags on. Hence, the IUSE=l10n_en is removed. All other English varieties' USE flags are set to be enabled by default, to avoid the need to manually set them in order to mimic the old behaviour (which might have been required in the most cases). Closes: https://bugs.gentoo.org/481618 Closes: https://github.com/gentoo/gentoo/pull/36552 Signed-off-by: Zurab Kvachadze <zurabid2016@gmail.com> Signed-off-by: Yixun Lan <dlan@gentoo.org> app-dicts/myspell-en/Manifest | 1 + app-dicts/myspell-en/myspell-en-20240601.ebuild | 62 +++++++++++++++++++++++++ 2 files changed, 63 insertions(+) Now a L10N="en" will pull in myspell-en, which will not be installable when non of the variants are also in L10N. > !!! The ebuild selected to satisfy "app-dicts/myspell-en" has unmet requirements. > - app-dicts/myspell-en-20240801::gentoo USE="" ABI_X86="(64)" L10N="-en-AU -en-CA -en-GB -en-US -en-ZA" > > The following REQUIRED_USE flag constraints are unsatisfied: > any-of ( l10n_en-AU l10n_en-CA l10n_en-GB l10n_en-US l10n_en-ZA ) One possible solution is to L10N+="en-US". But that is weird and the commit mentioned something about being backwards compatible, which does not seem to work as expected. I would expect that a simple "en" would simply still install all variants. (In reply to Henning Schild from comment #14) > Now a L10N="en" will pull in myspell-en, which will not be installable when > non of the variants are also in L10N. > > > !!! The ebuild selected to satisfy "app-dicts/myspell-en" has unmet requirements. > > - app-dicts/myspell-en-20240801::gentoo USE="" ABI_X86="(64)" L10N="-en-AU -en-CA -en-GB -en-US -en-ZA" > > > > The following REQUIRED_USE flag constraints are unsatisfied: > > any-of ( l10n_en-AU l10n_en-CA l10n_en-GB l10n_en-US l10n_en-ZA ) Oh, yeah, I tested a bit and it seems to be the case when the L10N variable is set to anything and it doesn't contain any of these English varieties. > One possible solution is to L10N+="en-US". But that is weird and the commit > mentioned something about being backwards compatible, which does not seem to > work as expected. > > I would expect that a simple "en" would simply still install all variants. Just to be clear, could you share the output of the two following commands: emerge --info quse -evp '=app-dicts/myspell-en-20240801' (Can't change to confirmed, used unconfirmed as a better status for the bug.) (In reply to zurabid2016 from comment #15) > Oh, yeah, I tested a bit and it seems to be the case when the L10N variable > is set to anything and it doesn't contain any of these English varieties. I am not really sure how to tackle this problem apart from either (1) enabling all the English varieties when all the L10N flags are off (which is totally counterintuitive, but will fix the issue) or (2) bringing back the l10n_en flag. I am not sure i would want to switch back to reproduce. I can tell you that i came from "L10N="de en nl"" in make.conf And now went to "L10N="de en en-GB en-US nl"". I guess reviving "en" for all variants would be the way to go. People that really want to remove certain variants can use package.use. Mapping "en" to anything but "all variants" or saying "en" means "all" unless at least one "en-*" is found seems to both have serious potential to breaking users expectations. So the few users who want to drop variants should be the ones to act. If you look at i.e. "pt-BR" you will see two ebuilds. I did not check the details but here a variant seems to live in its own package. So whatever gets done should probably be done the same way for all languages and their variants. For me that smells more like a case for an eselect script, and ebuilds simply always install all variants. I've got the same error:
> emerge -uND --with-bdeps=y --verbose-conflicts --backtrack=30 -pv @world
>
> hese are the packages that would be merged, in order:
>
> Calculating dependencies... done!
> Dependency resolution took 9.76 s (backtrack: 0/30).
>
>
> !! The ebuild selected to satisfy "app-dicts/myspell-en" has unmet requirements.
> app-dicts/myspell-en-20240801::gentoo USE="" ABI_X86="(64)" L10N="-en-AU -en-CA -en-GB -en-US -en-ZA"
>
> The following REQUIRED_USE flag constraints are unsatisfied:
> any-of ( l10n_en-AU l10n_en-CA l10n_en-GB l10n_en-US l10n_en-ZA )
>
> dependency required by "app-text/hunspell-1.7.2-r1::gentoo" [installed])
> dependency required by "app-text/enchant-2.6.1::gentoo" [installed])
> dependency required by "app-text/gspell-1.12.2::gentoo" [installed])
> dependency required by "app-editors/mousepad-0.6.2::gentoo" [installed])
> dependency required by "xfce-base/xfce4-meta-4.18-r1::gentoo" [installed])
> dependency required by "@selected" [set])
> dependency required by "@world" [argument])
>
> * IMPORTANT: 52 news items need reading for repository 'gentoo'.
> * Use eselect news read to view new items.
(In reply to Henning Schild from comment #18) > If you look at i.e. "pt-BR" you will see two ebuilds. I did not check the > details but here a variant seems to live in its own package. > > So whatever gets done should probably be done the same way for all languages > and their variants. > > For me that smells more like a case for an eselect script, and ebuilds > simply always install all variants. Removing all the USE flags from myspell-en and installing all the varieties unconditionally seems like a sensible solution (In reply to zurabid2016 from comment #20) > Removing all the USE flags from myspell-en and installing all the varieties > unconditionally seems like a sensible solution This solution is actually quite contrary to what the author of the bug wanted... Maybe installing the US variant unconditionally and all the other based on L10N flags? Honestly, to me it doesn't even make sense that the L10N variable doesn't work as USE, i.e. USE flags must be explicitly disabled, but setting to L10N to *anything* will disable everything that is not listed. Honestly, I don't understand the problem. `app-text/hunspell` has `en` - "all Englishes" (or "standard English"?). `app-dicts/myspell-en` has several English. And can have `en` - "all Englishes" (or "standard English"?). They turn on need. Is there an issue? (In reply to Alexander Kurakin from comment #22) > Honestly, I don't understand the problem. > > `app-text/hunspell` has `en` - "all Englishes" (or "standard English"?). > > `app-dicts/myspell-en` has several English. And can have `en` - "all > Englishes" (or "standard English"?). The issue is that there is no "standard English". app-dicts/myspell-en contains dictionaries for US English, Canadian English, British, New Zealand and Australian dialects of English, there is no "standard English", we have to choose between these. The issue with 'en' being a USE flag is that it doesn't make sense. Okay, if it's turned on, all the language variants are installed, we're good. But what if it's turned off? Nothing is installed? Or do we look at the regional USE flags? And what if those are disabled? You see, too many questions, it's kinda broken. We can't toggle **English** on the **English** dictionary. However, bringing back the 'en' flag might be the only option compatibility-wise. > They turn on need. Is there an issue? (In reply to Maxim P. Dementiev from comment #19) > I've got the same error: > > > emerge -uND --with-bdeps=y --verbose-conflicts --backtrack=30 -pv @world > > > > hese are the packages that would be merged, in order: > > > > Calculating dependencies... done! > > Dependency resolution took 9.76 s (backtrack: 0/30). > > > > > > !! The ebuild selected to satisfy "app-dicts/myspell-en" has unmet requirements. > > app-dicts/myspell-en-20240801::gentoo USE="" ABI_X86="(64)" L10N="-en-AU -en-CA -en-GB -en-US -en-ZA" > > > > The following REQUIRED_USE flag constraints are unsatisfied: > > any-of ( l10n_en-AU l10n_en-CA l10n_en-GB l10n_en-US l10n_en-ZA ) > > > > dependency required by "app-text/hunspell-1.7.2-r1::gentoo" [installed]) > > dependency required by "app-text/enchant-2.6.1::gentoo" [installed]) > > dependency required by "app-text/gspell-1.12.2::gentoo" [installed]) > > dependency required by "app-editors/mousepad-0.6.2::gentoo" [installed]) > > dependency required by "xfce-base/xfce4-meta-4.18-r1::gentoo" [installed]) > > dependency required by "@selected" [set]) > > dependency required by "@world" [argument]) > > > > * IMPORTANT: 52 news items need reading for repository 'gentoo'. > > * Use eselect news read to view new items. https://github.com/gentoo/gentoo/pull/36552#issuecomment-2397538944: > It should be `en-US` in `L10N`, not `en_US`: a dash, not an underscore. > The same goes for `ru-RU`, `en-GB` and `fr-FR`. They should have dashes, not underscores (In reply to zurabid2016 from comment #23) > (In reply to Alexander Kurakin from comment #22) > > Honestly, I don't understand the problem. > > > > `app-text/hunspell` has `en` - "all Englishes" (or "standard English"?). > > > > `app-dicts/myspell-en` has several English. And can have `en` - "all > > Englishes" (or "standard English"?). > > The issue is that there is no "standard English". app-dicts/myspell-en > contains dictionaries for US English, Canadian English, British, New Zealand > and Australian dialects of English, there is no "standard English", we have > to choose between these. > > The issue with 'en' being a USE flag is that it doesn't make sense. Okay, if > it's turned on, all the language variants are installed, we're good. > But what if it's turned off? Nothing is installed? Or do we look at the > regional USE flags? And what if those are disabled? > > You see, too many questions, it's kinda broken. We can't toggle **English** > on the **English** dictionary. However, bringing back the 'en' flag might be > the only option compatibility-wise. Ok, now I understand. There is no `en` specification for `L10N`. (And yes, this is applicable for each https://packages.gentoo.org/useflags/l10n_en.) Another question, is there a practice in Gentoo: "a flag which is the conjuction of other flags"? |
