Not really the same issue, but possibly tangentially related:

https://bugs.mageia.org/show_bug.cgi?id=3394
https://bugs.mageia.org/show_bug.cgi?id=1030

I'd point out that while this example is, perhaps, is due to a user error, the concept goes beyond these details.  Other support threads may be found where someone has an rpmdrake problem that ultimately requires use of command-line tools to show the reason the operation fails.

Granted that at some level, it is not necessarily reasonable to expect the same level of functionality from a GUI as one might gain from a command line tool, but it does seem reasonable to expect that error reporting is at least as good.

Also, note that it just took a simple oversight to get into this situation.  When enabling 32-bit repositories, I wasn't really doing things slowly and carefully enough.  I saw the check mark on the update media but wasn't looking at the title bar (because the list of media is SOooo long).

It is kind of noteworthy that the issue that bug 3394 raises would have been tremendously helpful in this situation even if error reporting was not dealt with (though I guess I feel that auto-enabling media is not a good idea; the user should have to give permission).

(In reply to Kevin Bulgrien from comment #0)
> Description of problem:
> 
> rpmdrake 6.32 fails to install packages and offers no hint as to why even
> though other tools can give more information.  For example, on a new system
> where 32-bit repositories are enabledd, but 32-bit update repositories are
> not enabled, it says:
> 
> Sorry, the following package cannot be selected:
> 
> - steam-1.0.0.68-2.mga8.nonfree.x86_64
> 
> This poses at least two problems:
> 
> 1) A package is not installable; users without command-line expertise get
> stuck.
> 2) One must use command-line tools to investigate.
> 
> I'm focusing on 2).
> 
> Version-Release number of selected component (if applicable):
> 
> rpmdrake-6.32-1.mga8.src.rpm (Mageia 8)
> 
> How reproducible:
> 
> Install a new system.
> 
> Enable the 32-bit repositories, but do not enable 32-bit update
> repositories.  Perhaps install 32-bit wine so that some 32-bit packages are
> installed.
> 
> For example:
> 
> $ urpmq --list-media active
> Core Release (distrib1)
> Core Updates (distrib3)
> Nonfree Release (distrib11)
> Nonfree Updates (distrib13)
> Tainted Release (distrib21)
> Core 32bit Release (distrib31)
> Nonfree 32bit Release (distrib36)
> Tainted 32bit Release (distrib41)
> 
>

That configuration is not recommended, you must add the Updates flavor for Tainted  and the 32bit repositories.

https://wiki.mageia.org/en/Mageia_8_Release_Notes#32_bit_repos_on_64_bit_systems

We had another recent example where a user couldn't install a -devel package from updates_testing, and it was also user error with their configured repositories, but rpmdrake not giving any information as to why the package was not selectable was very unhelpful.  Assigning to Mageia tools maintainers.

Assignee: bugsquad => mageiatools

I've got the same problem trying to install steam package:

>sudo urpmi steam
>[sudo] Mot de passe de davidcosse : 
>Le paquetage demandé ne peut pas être installé :
>steam-1.0.0.70-3.mga9.nonfree.x86_64 (car libmesagl1 est non satisfait)

CC: (none) => saveurlinux

I also see rpmdrake giving no explanation sometimes.  Irritating.

IIRC, urpmi gives better output when that happens.

---

@david Cossé, from the output in your specific case,
I guess you need to enable 32 bit repositories, see
https://wiki.mageia.org/en/Ways_to_install_programs#Steam

CC: (none) => fri

(In reply to Kevin Bulgrien from comment #0)
> Description of problem:
> 
> rpmdrake 6.32 fails to install packages and offers no hint as to why even
> though other tools can give more information.  For example, on a new system
> where 32-bit repositories are enabledd, but 32-bit update repositories are
> not enabled, it says:
> 
> Sorry, the following package cannot be selected:
> 
> - steam-1.0.0.68-2.mga8.nonfree.x86_64
> 
> This poses at least two problems:
> 
> 1) A package is not installable; users without command-line expertise get
> stuck.
> 2) One must use command-line tools to investigate.
> 
> I'm focusing on 2).
> 
> Version-Release number of selected component (if applicable):
> 
> rpmdrake-6.32-1.mga8.src.rpm (Mageia 8)
> 
> How reproducible:
> 
> Install a new system.
> 
> Enable the 32-bit repositories, but do not enable 32-bit update
> repositories.  Perhaps install 32-bit wine so that some 32-bit packages are
> installed.
> 
> For example:
> 
> $ urpmq --list-media active
> Core Release (distrib1)
> Core Updates (distrib3)
> Nonfree Release (distrib11)
> Nonfree Updates (distrib13)
> Tainted Release (distrib21)
> Core 32bit Release (distrib31)
> Nonfree 32bit Release (distrib36)
> Tainted 32bit Release (distrib41)
> 

You don't have enough repositories enabled

urpmq --list-media active
Core Release
Core Updates
Nonfree Release
Nonfree Updates
Tainted Release
Tainted Updates
Core 32bit Release
Core 32bit Updates
Nonfree 32bit Release
Nonfree 32bit Updates
Tainted 32bit Release
Tainted 32bit Updates

As suggested on wiki if you enable a repository you should enable the Updates version also

 LC_ALL=C urpmi --test steam
To satisfy dependencies, the following packages are going to be installed:
(test only, installation will not be actually done)
  Package                        Version      Release       Arch    
(medium "Core Release")
  gnu-free-fonts-common          20120503     11.mga9       noarch  
  gnu-free-mono-fonts            20120503     11.mga9       noarch  
  steam-udevrules                1.0.0.70     2.mga9        noarch  
(medium "Nonfree Release")
  steam                          1.0.0.70     3.mga9.nonfr> x86_64  
(medium "Core 32bit Release")
  libdbus-glib1_2                0.112        2.mga9        i586    
4.8MB of additional disk space will be used.
3.8MB of packages will be retrieved.
Proceed with the installation of the 5 packages? (Y/n) y


    https://mirror.math.princeton.edu/pub/mageia/distrib/9/x86_64/media/core/release/steam-udevrules-1.0.0.70-2.mga9.noarch.rpm
    https://mirror.math.princeton.edu/pub/mageia/distrib/9/x86_64/media/core/release/gnu-free-mono-fonts-20120503-11.mga9.noarch.rpm
    https://mirror.math.princeton.edu/pub/mageia/distrib/9/x86_64/media/core/release/gnu-free-fonts-common-20120503-11.mga9.noarch.rpm
    https://mirror.math.princeton.edu/pub/mageia/distrib/9/x86_64/media/nonfree/release/steam-1.0.0.70-3.mga9.nonfree.x86_64.rpm    
    https://mirror.math.princeton.edu/pub/mageia/distrib/9/i586/media/core/release/libdbus-glib1_2-0.112-2.mga9.i586.rpm            
installing steam-1.0.0.70-3.mga9.nonfree.x86_64.rpm steam-udevrules-1.0.0.70-2.mga9.noarch.rpm gnu-free-fonts-common-20120503-11.mga9.noarch.rpm gnu-free-mono-fonts-20120503-11.mga9.noarch.rpm libdbus-glib1_2-0.112-2.mga9.i586.rpm from /var/cache/urpmi/rpms
Preparing...                     ##################################################################################################
Installation is possible

(In reply to Kevin Bulgrien from comment #0)
> $ sudo urpmi steam
> The following packages can't be installed because they depend on packages
> that are older than the installed ones:
> libdri-drivers-20.3.4-2.mga8
> libmesagl1-20.3.4-2.mga8
> libgl1-1.3.2-16.mga8
> steam-1.0.0.68-2.mga8.nonfree
> libmesaglu1-9.0.1-2.mga8
> libgldispatch0-1.3.2-16.mga8
> libglx0-1.3.2-16.mga8
> Continue installation anyway? (Y/n) n
> 
You maybe bad sync mirror

what url do you have?

Provide output of
urpmi --test steam


Try choose other mirror

Or you have issues with packages from backport

Give the output of
urpmq --not-available

The install failure was resolved by enabling the update repository as suggested above.  The command-line urmpi showed a more meaningful message.  The GUI utility should be more informative as probably a decent number of users will not expect to have to discover the cause of such a problem by using the command line utility.  Though the install issue on my system is unresolved, I do not consider the bug "resolved", but also think this doesn't really require the extra  information requested.

Then close as invalid for request rpmdrake give more info when some fail 
Please open other bug

Status: NEW => RESOLVED
Resolution: (none) => INVALID

I don't understand.  The bug is correctly described in the title.  The bug is that the tool does not give information about why the package cannot be installed, leaving the user clueless about what mitigation might be attempted.  The error message shown is not helpful.  One has to "just know" to check to see if update media not being selected is the problem, or one has to use a different tool that does hint what might be wrong.

The bug that the tool is not helpful to a non-expert is not resolved.

Other commenters understand what the problem is, so I do not understand why it is not clear to katnatek, or I do not understand what nit about the bug report I do not comprehend.  This is bad behavior on the part of rpmdrake.  It is not an install problem per se.  The problem is that rpmdrake does not offer the additional detail that urpmi offers, so the rpmdrake implementation clearly is sub-par.

(In reply to Kevin Bulgrien from comment #13)
> The bug that the tool is not helpful to a non-expert is not resolved.

This is true.  This is not the first time, and I have nagged about it before.

Please see if there is already an open bug... if so set this as duplicate of it - I gotta leave keyboard for today.

Resolution: INVALID => (none)
Status: RESOLVED => REOPENED

(In reply to Kevin Bulgrien from comment #14)
I did feel like need a report for the enhance suggestion due the bad repositories configuration that make you open the report, i will watch this because myself bite some times by this due all the posible causes (including myself ;) )

CC: (none) => j.alberto.vc

There is a "how to reproduce" in the original post.  Is it actually unclear how to get the information needed from that?  There was no bad sync.  The original post also shows urpmi output that might have been helpful in the GUI.  I can set up a VM and collect output of those commands, but it kind of looks like context wasn't considered fully when those requests were made.  Is the additional output actually still needed considering all the information in the original post?

(In reply to Kevin Bulgrien from comment #17)
In similar situations some one ask me open new bug, just make the same
Sorry if i bother you

There seems to be a language barrier on katnatek's side. There is no new bugreport needed. The initial failure description from Kevin is clear and repeatable with all packages that are not installable (dosn't matter because of a conflict or something else).

(In reply to sturmvogel from comment #19)
As say, just act as ask me to act in similiar situations, please forget the theme
The bug is reopened , i make a mistake and thats all