Description of problem:
When using the MCC tool to add online media, the 32-bit core_release and 32-bit core_updates repositories are not automatically enabled as they have been with past releases. This happens whether the Mirror List or a specific mirror is used. The repositories are easily enabled by checking the boxes in the gui, indicating that the problem is not one of a bad download from the mirror.
The 32-bit nonfree_release and nonfree_updates repositories ARE enabled by default, as has been done with past releases.
It would seem to me that, to be consistent we should either enable the 32-bit core and update repositories by default, or disable all of the 32-bit repositories by default.
This has been an ongoing situation, so there may be a bug on it already, but I don't seem to have the skill to find it. Or, I suppose this could be a new policy and I missed the discussion. I thought this was a good way to ask, either way.
urpmi (?), rpmdrakeAssignee:
When adding media from MCC, 32-bit core_release and 32-bit core_updates repositories not enabled by default =>
When adding media from MCC, 32-bit core_release and 32-bit core_updates repositories not enabled by default, but 32-bit nonfree is enabled.
It's intentional to not enable 32bit medias anymore, but there is a bug in drakx that enables the 32bit nonfree if 64bit nonfree gets enabled
In bug 24438, "PC LX" showed that 32bit tainted is enabled by default, too, so adding that to the summary of this report.
When adding media from MCC, 32-bit core_release and 32-bit core_updates repositories not enabled by default, but 32-bit nonfree is enabled. =>
When adding media from MCC, 32-bit core_release and 32-bit core_updates repositories aren't enabled by default, but 32-bit nonfree and tainted are enabled.
Confirmed in current Cauldorn.
(In reply to Thomas Backlund from comment #1)
> It's intentional to not enable 32bit medias anymore, but there is a bug in
> drakx that enables the 32bit nonfree if 64bit nonfree gets enabled
Do you know what commit introduce the change to not enable 32bit medias? The culprit is likely there, where nonfree and tainted were probably missed.
I just had occasion to do an install from the round 1 beta3 M7 Classical iso. I did not go after updates with the installer, partly because the wifi on that laptop can't be started until after the first boot.
After the first boot and starting the wifi, I used the MCC tool to add a speecific mirror, in this case the math.princeton mirror. When finished, the only 32-bit repositories that were activated by default were Nonfree_release and Nonfree_updates. None of the tainted repositories were activated by default, 64-bit OR 32-bit. As is my custom, I activated tainted_release, tainted_updates, 32-bit Core_Release, 32-bit Core_Updates, and the 32-bit tainteds manually.
I have noticed in past Mageias where, if you add additional media or replace MIRRORLIST with a specific mirror, whatever repositories were active before the addition or replacement were also automatically activated in the addition or replacement. I just checked that with that "fresh" laptop install, and while the 64-bit and 32-bit tainted repositories on the new mirror had been activated, as they are on the original mirror, 32-bit Core_Release and 32-bit Core_Updates were not.
Fixed in urpmi-8.116-1.
Confirmed as of the Mageia 7 RC Round 4 isos.