Bug 18315

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) => UPSTREAM
See Also: (none) => https://bugzilla.redhat.com/show_bug.cgi?id=1266761
Summary: 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 capability
Severity: 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

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 ;-)

(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...