When updating firefox with "dnf upgrade" two days ago, dnf auto-selected firefox-af to be installed, even if I didn't yet have locales-af: Installing: firefox-af noarch 45.1.0-1.mga6 mageia-cauldron-core 396 k hunspell-af noarch 0.20080825.1-14.mga6 mageia-cauldron-core 500 k locales-af x86_64 2.22-4.mga6 mageia-cauldron-core 13 k Upgrading: firefox x86_64 45.1.0-2.mga6 mageia-cauldron-core 41 M When installing gcompris with "dnf install gcompris", I don't get a choice, either: Installing: gcompris x86_64 15.10-2.mga6 mageia-cauldron-core-x86_64 3.7 M gcompris-boards noarch 15.10-2.mga6 mageia-cauldron-core-x86_64 115 M gcompris-sounds-af noarch 15.10-2.mga6 mageia-cauldron-core-x86_64 926 k locales-af x86_64 2.22-4.mga6 mageia-cauldron-core-x86_64 13 k Of course I'm capable of installing firefox-nl or the gcompris-sounds package I prefer. However, I've been spoiled by urpmi which lets me select between the versions for all locales that are installed (and, kindly, only for those, so not for not-installed locales), like this: In order to satisfy the 'gcompris-sound[== 15.10-2.mga6]' dependency, one of the following packages is needed: <all 9 gcompris-sound-* packages matching my 9 locales-* listed here> What is your choice? (1-9) It would be really nice if dnf would give a similar choice, it would make dnf even more perfect ;-)
This is occurring by design. DNF provides libsolv (through hawkey) the transaction parameters, in which libsolv processes and returns the full set. At that point, DNF makes some decisions to resolve the "unresolvable" states (which are basically situations like this). In the case of locales, Fedora didn't encounter this issue in the past because they used composition metadata (comps metadata) to handle the language setup. With Fedora 24, they've moved to using reverse dependencies and conditional dependencies to handle this[1]. Unfortunately, this option is not possible for us because we are trying to maintain compatibility with urpmi, which is not capable of processing either reverse dependencies or conditional dependencies. However, what you are asking for is also useful in other cases, and I've previously filed an RFE for this, so I'm adding this to the upstream bug. [1]: https://fedoraproject.org/wiki/Changes/LangpacksInstallationWithRPMWeakDependencies
Keywords: (none) => UPSTREAMSee Also: (none) => https://bugzilla.redhat.com/show_bug.cgi?id=1266761Summary: dnf install and dnf upgrade auto-select Afrikaans language package, even if locales-af wasn't installed => [RFE] DNF should have an option to allow user to select options that equally provide a capabilitySeverity: normal => enhancement
So, Michael Schroeder (mls) pushed changes to libsolv that add urpm-like solution ordering for locales[1]. I have backported this new code to our libsolv, and applied a patch to hawkey to use this new code. The code is present in libsolv-0.6.20-2.mga6 and hawkey-0.6.3-2.mga6. Please update and see if the situation is improved. DNF will automatically take advantage of the new configuration in the hawkey library and hawkey will take advantage of the new code path in libsolv. [1]: https://github.com/openSUSE/libsolv/commit/565280da80a62dbd48bcd30043149be210e3b5c3
My own test indicates that this issue doesn't come up, as you can see here: [ngompa@mgacauldron-dnftst ~]$ rpm -qa | grep locales locales-en-2.22-4.mga6 locales-2.22-4.mga6 [ngompa@mgacauldron-dnftst ~]$ sudo dnf install gcompris Last metadata expiration check: 6:26:34 ago on Fri May 13 22:25:49 2016. Dependencies resolved. ================================================================================ Package Arch Version Repository Size ================================================================================ Installing: gcompris x86_64 15.10-2.mga6 mageia-cauldron-core 3.7 M gcompris-boards noarch 15.10-2.mga6 mageia-cauldron-core 115 M gcompris-sounds-en noarch 15.10-2.mga6 mageia-cauldron-core 11 M gnome-python x86_64 2.28.1-11.mga6 mageia-cauldron-core 83 k gnome-python-bonobo x86_64 2.28.1-11.mga6 mageia-cauldron-core 61 k gnome-python-canvas x86_64 2.28.1-11.mga6 mageia-cauldron-core 24 k gnucap x86_64 20060830-13.mga6 mageia-cauldron-core 913 k gnuchess x86_64 6.2.2-2.mga6 mageia-cauldron-core 1.5 M lib64SDL_Pango1 x86_64 0.1.2-15.mga6 mageia-cauldron-core 14 k lib64SDL_image1.2_0 x86_64 1.2.12-9.mga6 mageia-cauldron-core 32 k lib64SDL_mixer1.2_0 x86_64 1.2.12-10.mga6 mageia-cauldron-core 73 k lib64SDL_ttf2.0_0 x86_64 2.0.11-8.mga6 mageia-cauldron-core 20 k lib64fltk1.3 x86_64 1.3.4-0.r11608.2.mga6 mageia-cauldron-core 514 k librsvg x86_64 2.40.15-1.mga6 mageia-cauldron-core 178 k pygtk2.0 x86_64 2.24.0-11.mga6 mageia-cauldron-core 683 k pyorbit x86_64 2.24.0-14.mga6 mageia-cauldron-core 50 k python-cairo x86_64 1.10.0-16.mga6 mageia-cauldron-core 33 k python-numpy x86_64 1:1.11.0-1.mga6 mageia-cauldron-core 6.6 M python-sqlite2 x86_64 2.6.3-8.mga6 mageia-cauldron-core 77 k tuxpaint x86_64 1:0.9.22-4.mga6 mageia-cauldron-core 9.5 M tuxpaint-config x86_64 0.0.13-6.mga6 mageia-cauldron-core 229 k tuxpaint-stamps noarch 2014.08.23-4.mga6 mageia-cauldron-core 153 M Transaction Summary ================================================================================ Install 22 Packages Total download size: 302 M Installed size: 456 M Is this ok [y/N]:
It's much better than it was: It now selects the alphabetically first of the installed languages: [root@cldrn_64 marja]# rpm -qa | grep locales locales-2.22-4.mga6 locales-pt-2.22-4.mga6 locales-ar-2.22-4.mga6 locales-en-2.22-4.mga6 locales-fr-2.22-4.mga6 locales-ru-2.22-4.mga6 locales-de-2.22-4.mga6 locales-zh-2.22-4.mga6 locales-es-2.22-4.mga6 locales-nl-2.22-4.mga6 [root@cldrn_64 marja]# LANGUAGE=C dnf install gcompris Last metadata expiration check: 0:20:43 ago on Sat May 14 21:06:49 2016. Dependencies resolved. =========================================================================== Package Arch Version Repository Size =========================================================================== Installing: gcompris x86_64 15.10-2.mga6 mageia-cauldron-core-x86_64 3.7 M gcompris-boards noarch 15.10-2.mga6 mageia-cauldron-core-x86_64 115 M gcompris-sounds-ar noarch 15.10-2.mga6 mageia-cauldron-core-x86_64 1.2 M Transaction Summary =========================================================================== Install 3 Packages Total size: 120 M Installed size: 156 M Is this ok [y/N]: I'm not against further improvement, though, getting a choice would still be nice ;-)
The code to activate this solver flag has been submitted upstream[1], though the work to give the user choices has not yet been explored. [1]: https://github.com/rpm-software-management/libhif/pull/122
It has now also been submitted to the hawkey library upstream: https://github.com/rpm-software-management/hawkey/pull/117
Summary: [RFE] DNF should have an option to allow user to select options that equally provide a capability => dnf install and dnf upgrade auto-select Afrikaans language package, even if locales-af wasn't installed
Summary: dnf install and dnf upgrade auto-select Afrikaans language package, even if locales-af wasn't installed => dnf install and dnf upgrade auto-select language package for the alphabetically first installed locales-*, instead of giving a choiceSource RPM: dnf-1.1.8-2.mga6 => dnf-1.1.9-3.mga6
See Also: (none) => https://bugs.mageia.org/show_bug.cgi?id=18810
The solver flag activation code is now upstream in libhif and hawkey, however the work to give the user choices has not yet been explored.
Thanks, Neal :-) It is nice to see progress ... I prefer steady progress over too many improvements in a short time, after which everyone's exhausted and the project drops dead ;-)
Depends on: (none) => 19974
(In reply to Neal Gompa from comment #1) > > In the case of locales, Fedora didn't encounter this issue in the past > because they used composition metadata (comps metadata) to handle the > language setup. With Fedora 24, they've moved to using reverse dependencies > and conditional dependencies to handle this[1]. Unfortunately, this option > is not possible for us because we are trying to maintain compatibility with > urpmi, which is not capable of processing either reverse dependencies or > conditional dependencies. So this is a bit of a lie, apparently. We *can* do this, urpmi just will ignore it, since it doesn't recognize the Supplements tag. However, I doubt we can implement it globally in the remaining development cycles for Mageia 6.
(In reply to Neal Gompa from comment #9) > (In reply to Neal Gompa from comment #1) > > > > In the case of locales, Fedora didn't encounter this issue in the past > > because they used composition metadata (comps metadata) to handle the > > language setup. With Fedora 24, they've moved to using reverse dependencies > > and conditional dependencies to handle this[1]. Unfortunately, this option > > is not possible for us because we are trying to maintain compatibility with > > urpmi, which is not capable of processing either reverse dependencies or > > conditional dependencies. > > So this is a bit of a lie, apparently. We *can* do this, urpmi just will > ignore it, since it doesn't recognize the Supplements tag. However, I doubt > we can implement it globally in the remaining development cycles for Mageia > 6. As a small update, we *can't* do this because our build system currently chokes on *any* rich dependencies in a spec file (since apparently it's parsing the spec file...). I found this out the hard way with dnfdragora, where it wouldn't let me do a rich Supplements (which would be ignored by urpmi but be used by DNF) because it considered it an invalid declaration in a spec file. So this definitely has to wait for Mageia 7, because we need to rework/replace the build system. Another bug will be filed about this shortly...
CC: (none) => ignatenko