Description of problem: We currently rely on custom resolving logic for handling langpacks and locales. However, with DNF, we can rely on built-in functionality in RPM and libsolv for resolving this properly. This will ensure that when users have selected specific locales to be installed, that all packages that have locale subpackages will get the correct ones automatically installed. Same goes for removal. This was implemented in Fedora using rich dependencies with the Supplements tag, and we can implement it in the same way. This will properly solve bug 18315, and will allow us to resolve bug 460 and bug 18810 as we transition tools to use DNF. Details on the Fedora Change that occurred in Fedora 24: https://fedoraproject.org/wiki/Changes/LangpacksInstallationWithRPMWeakDependencies Details on the packaging implementation from Fedora: https://fedoraproject.org/wiki/Packaging:Langpacks
While this can be implemented in Mageia 6 without compromising compatibility with urpmi, this bug will be targeted at Mageia 7 because we're too late in the development process.
Target Milestone: --- => Mageia 7
Blocks: (none) => 18315
See Also: (none) => https://bugs.mageia.org/show_bug.cgi?id=460
See Also: (none) => https://bugs.mageia.org/show_bug.cgi?id=18810
CC: (none) => mageiaAssignee: bugsquad => thierry.vignaud
It would be nice if work on this could already be started, it would be great to have better support for systems with multiple human languages and for switching the language of a system. Below is a list of the SRPMS of as many lang/locale packages as possible. I wrote "aspell-*" to cover the entire set of aspell-af, aspell-am, etc. SRPMs and did the same for some other tools where the languages have their own SRPMs. abiword-docs aspell-* calligra-l10n childsplay firefox-l10n fp-ide-* freeswitch gcompris gimp-help hunspell-* hyphen-* jortho kde-l10n kompozer-l10n kompozer-myspell-l10n libguestfs libreoffice locales lure-* mageia-doc man-pages-* mythes-* psi scim-tables squirrelmail stardict-*-*-* tesseract thunderbird-l10n xmltv zinnia-tomoe CC'ing their maintainers and also (for the nobody packages) all packagers collectively. Please say so if the list above is not complete or when a SRPM(-set) doesn't belong in it. We should probably clone this report for each application. If that's not needed for one or more SRPMs, because you'll fix them without needing a separate report, then please say so :-)
CC: (none) => doktor5000, fundawang, geiger.david68210, jani.valimaa, joequant, lists.jjorge, loginov_alex, luigiwalser, luis.daniel.lucio, marja11, matteo.pasotti, pkg-bugs, shlomif, zen25000
This is a partial incomplete solution. It won't work for the vast majority of packages where the only solution is to reinstall the packages after the choosen locales-XX pkgs have been installed... This this is not a working solution for adding new locales...
@Thierry: Actually, I believe that it will resolve itself upon update, since the Supplements would kick in and install them. Essentially, it'd be like this for us in most cases: > Supplements: (%{name} = %{version}-%{release} and locales-<langcode>) But you are correct that if someone were to use urpmi to update, it wouldn't help anything, and then they would have to do "sudo dnf reinstall locales-<lang>" to trigger the behavior. However, I believe it is still a substantial improvement to the current situation.
Oh, and I forgot to mention that "dnf install locales-<lang>" would then properly pull in all the associated langpacks for all installed applications, and with how DNF tracks packages, I believe that uninstalling a locale will also make all the langpacks get uninstalled with it (as they are marked as dep-installed).
Please read again why I wrote 1) most packages don't have langpacks, so Supplements won't help at all 2) aka they ship all translations in the main packages 3) rpmlib onlt install the files from /usr/share/locales/* that match lang %_install_langs This this is not a working solution for adding new locales...
(In reply to Thierry Vignaud from comment #6) > Please read again why I wrote > 1) most packages don't have langpacks, so Supplements won't help at all > 2) aka they ship all translations in the main packages > 3) rpmlib onlt install the files from /usr/share/locales/* that match lang > %_install_langs > > This this is not a working solution for adding new locales... Well, if they're all installed, then it doesn't matter anyway. This is about packages that do have langpacks split out into different packages. The problem we're trying to solve is how to deal with packages that do have split up langpack subpackages.
(In reply to Marja van Waes from comment #2) > Below is a list of the SRPMS of as many lang/locale packages as possible. I > wrote "aspell-*" to cover the entire set of aspell-af, aspell-am, etc. SRPMs > and did the same for some other tools where the languages have their own > SRPMs. > ..snip.. > xmltv xmltv is false positive. xmltv-grabbers-<country code> pkgs provides tv show info grabbers for different countries and not language/locale files.
CC: jani.valimaa => (none)
(In reply to Neal Gompa from comment #7) You don't understand. Let's try again for the 3rd time: Yes in the vast majority, the package contains *all* the translations. But rpmlib will only install *some* of them, those matching the %_install_lang macros and thus one will only have installed the translations corresponding to the locales-XX packages installed... Thus what you suggests is a very partial solution.
(In reply to Thierry Vignaud from comment #9) > (In reply to Neal Gompa from comment #7) > You don't understand. > Let's try again for the 3rd time: > Yes in the vast majority, the package contains *all* the translations. > But rpmlib will only install *some* of them, those matching the > %_install_lang macros and thus one will only have installed the translations > corresponding to the locales-XX packages installed... > Thus what you suggests is a very partial solution. I do understand, however, I think you don't understand: That is not the problem I'm trying to fix. Fixing that requires refactoring the packages to actually create langpack subpackages. There is nothing I can do about that particular problem right now. What I want to fix is the existing langpack packages so that they install like they should. I understand that this is a partial solution, however, it is only a partial solution until we stop using %_install_lang and start splitting langpacks and locales in more packages.
won't that add useless packages and overload the mirors ?
(In reply to Nicolas Lécureuil from comment #11) > won't that add useless packages and overload the mirors ? Language (ie. free software in english) is the big problem for most users. So I disagree calling useless the new packages needed for language. For now we can do better for this packages, this will already give a very good experience for installs from Live media : all locales come inside for %install_lang, and with this we will also have the package-lang* fixed! But I don't get how to implement this in Mageia. A wiki article would be good?
Another Fedora reference on how this change would work: https://fedoraproject.org/wiki/Changes/Replace_Comps_Language_Group_With_Langpacks