Most likely you need to enable 32bit repositories, as steam needs i586 packages.
MCC/Software Management/Configure media sources/Core 32bit Release

CC: (none) => arusanu

This question comes up frequently.

Maybe we should note in package description that i586 repo is needed?

CC: (none) => fri

Certainly. Or enable 32bit repositories per default.
For an everyday user installation of software should be click and forget.
I'm certainly not an newcomer to Linux and to Mageia. But I have been struck by this stupid error before. Apparently I seem to forget. And I always end up with 32bit enabled.

Btw. Now I cannot install steam due to 
libllvm-devel-11.0.1-2.rc2.1.mga8.i586 (grundet uopfyldt llvm-11.0.1-2.rc2.1.mga8.i586)

I guess it's under compilation. Patience, Hans! Patience!

Cool! I got steam installed. But it still remains to decide what to do with the 32bit repositories

We should not enable 32-bit on 64 bit installs automatically.

How to best inform a newbie user to enable them?

What's the status of this?

CC: (none) => ouaurelien

Well, as long as there is no solution, I guess the big is still open.
I still opt for enabling 32 bit per standard. I always end at that anyway quite soon after reinstalling Mga

This is not the only pkg that needs 32-bit repos enable (often also Wine).
I think Morgan's suggestion is best:
> Maybe we should note in package description that i586 repo is needed
When you select a package in MCC-Manage Software, Add/Remove software, the description is shown - which would include this warning if it was there. There are packages with special requirements which mention them in their description, so this is normal practice.

If you use urpmi directly, you are clued up. If by precaution you start with
 $ urpmq -i <package>
you would see it.
I suppose ideally trying to install such a package would check for 32-bit repos first...

Assigning to akien for this SRPM.

Assignee: bugsquad => rverschelde

(In reply to Hans Micheelsen from comment #8)
> Well, as long as there is no solution, I guess the big is still open.
> I still opt for enabling 32 bit per standard. 

We wont.

There is no point if forcing 32bit medias on all the users that happily work with 64bit-only setups

More detail: Apart from the risk of getting unwanted 32 bit versions (i.e if 64 bit repo lag but not 32 bit), looking for packages and updates takes longer the more repos that are enabled.

(In reply to Thomas Backlund from comment #10)
> (In reply to Hans Micheelsen from comment #8)
> > I still opt for enabling 32 bit per standard. 
> There is no point if forcing 32bit medias on all the users that happily work
> with 64bit-only setups
(In reply to Morgan Leijström from comment #11)
> More detail: Apart from the risk of getting unwanted 32 bit versions (i.e if
> 64 bit repo lag but not 32 bit), looking for packages and updates takes
> longer the more repos that are enabled.
I agree with both. 32-bit repos on a 64-bit system are a pain as Morgan says; also because they show both architectures in package searching, which is confusing.

This still leaves the note in the package description, non? One imagines this would be easy.

Description telling which i586 repos is needed, is the way.


We experienced users understand to look for the missing lib* in 32 bit repos, but not most users.

And really the message "unsatisfied libudev1"
is for common people not obvious it mean "could not find the 32 bit package libudev1 in enabled repositories"

(except for us who learned this internal language...)

We've learned the hard way. Enabling the 32 bit repos by default causes more
people to report having difficult to debug problems, especially when upgrading,
then the people reporting problems when they are disabled. For those reporting
problems with them not being enabled, they are easy to debug.

There are people in both groups who do not report the problems they encounter.
There's no way to know how many.

The 32 bit repos will not be enabled by default.

Adding a note in the package description for Mageia packages, is easy, and just
has to get done. For third party packages there is nothing we can do.

CC: (none) => davidwhodgins

Apart from adding the note in this package,

One wonder if urpmi could maybe hint in a user understandable way, i.e give url to a wiki page, describing reasons and remedies for most common problems.

> BEWARE:
> Only the above 32bits repos (core/release and core/updates) must be enabled.
> (Don't enable nonfree/tainted 32bits version).
> Next, only maintain 32bits core/updates repo enabled for updates to already
> installed 32bits libraries.
> This will prevent further installation of new 32bits software, if you
> install later other software.

That part is incorrect or misleading. If you want to use apps that require 32-bit libraries, you can't cherrypick only Core libraries during the install and then disable it. You may end up with a broken system if some libraries are updated in x86_64 and not i586.

You should enable the same repos in 32-bit that you have enabled in 64-bit, and leave them enabled. So if you use e.g. Core, Nonfree and Tainted, you should enable the equivalent 32-bit repos in Release and Updates.

That's why I said to leave the 32bits core/updates enabled.
Already installed 32bits libraries/Applications will be updated even when x86_64 ones are updated.

My current Steam's installation works as is.


All I wanted to prevent is to prevent newer x86_64 applications installation to also pulls 32 bits part. I do see this in past and I don't want.
Steam has already pulled all 32 bits libraries/applications he needs. I don't want to bloat my system.

But I you say at least 32 bits core/release should be enabled I will switch it enabled. But I really don't know why because it is frozen state as soon as the distribution is released.
I agree between RC1 and release it must be enabled in order to get last time updates and fixes.

Regards,

Updates can add new required dependencies, so if you enable only Core 32bit Updates and not Core 32bit Release, you can end up in a situation where updates are impossible because an Updates package has a dependency on Release which can't be satisfied. I've had to debug a number of such issues here because of similar dangerous advice that was given to users. If you know what you're doing and how to debug update issues it's ok to disable Release, but this shouldn't be documented as the recommended approach, as it's effectively putting oneself in an unsupported configuration.

Ok Rémi.

Modifying the approach:
On x86_64, correct path to install Steam is:

1) Be sure Mageia 8 is updated, with mgaapplet since Release, or doing:
# urpmi --auto-update
as root.

2) Activate 32bits core/release and core/updates repositories with drakrpm-edit-media (Configure media source for install and update) in Mageia Control Centre.( MCC)

3) Install Steam with rpmdrake (Install and Remove Software) in MCC.

Let's install dependencies.
Enjoy. Steam will auto-update itself thereafter.
No need to do something else.
If 32bits repos are not enabled, Steam can't install.

Back to BR:
Not reproduced on updated M8 x86_64 Plasma installation from Classic public RC1 ISO.

So this must land to release note. There is no bug.

I believe I nailed it in last paragraph at
https://wiki.mageia.org/en/Mageia_8_Release_Notes#The_Mageia_online_repositories

Please check.

IMO, optimally we should create one small Wiki page each for Steam and PlayOnLinux, and from there point to another small page about 32 bit repos on 64 bit systems (or a subchapter on a page about repos, believe we have one...?)

Keywords: FOR_RELEASENOTES8 => IN_RELEASENOTES8

(In reply to Dave Hodgins from comment #14)
> Adding a note in the package description for Mageia packages, is easy, and
> just has to get done. For third party packages there is nothing we can do.

Did this happen?
If not we should spawn a bug for it.

Release notes look great, thanks.

I added a note in the package description, though it needs a freeze push to make it to the mirrors.

Thanks

Great with a note.

Likewise, I think a note should be added to PlayOnLinux?

PlayOnLinux is unmaintained and was dropped from Mageia 8.

Ah, thanks, we should not mention PlayOnLinux then in that text I modified on ReleaseNotes.  I will fix that.

Instead PlayOnLinux should go somewhere in https://wiki.mageia.org/en/Mageia_8_Release_Notes#Packages_removed_from_the_distribution

Will it be removed upon update, or still installed if it was installed on Mageia7 (and if so will it still work?)

(In reply to Morgan Leijström from comment #26)
> Will it be removed upon update, or still installed if it was installed on
> Mageia7 (and if so will it still work?)

I just tested, it does get removed automatically by `task-obsolete`. The mga7 RPM cannot be installed because it requires `wxPython` which is not provided in mga8. After forcing its installation with `urpmi --allow-nodeps`, I confirmed that it's not working (Python traceback due to missing `wxversion`).

I also tested the tarball from https://www.playonlinux.com/en/download.html but it doesn't work either due to missing `wxversion`.

So there's no option to use POL anymore on Mageia 8, until it's possibly ported to Python 3 (but I wouldn't bet on it as upstream development is quite slow/stalled).

We could advise users to look into Lutris, which fulfills part of what POL was used for and does it much better.

Thanks :)

Updated: https://wiki.mageia.org/mw-en/index.php?title=Mageia_8_Release_Notes&type=revision&diff=50297&oldid=50289