urpmi wants to download noarch from the 32bit repository on a x86_64 host

[Jeff Johnson]

arch affinity needs improvements

[Doktor5000 (doktor5000)]

Description of problem:

urpmi wants to install 32bit packages from the 32bit media, instead of the correct x86_64 packages. See for example this:

$ LC_ALL=C sudo urpmi rpm-build rpmlint
To satisfy dependencies, the following packages are going to be installed:
   Package Version Release Arch
(medium "Core Release (distrib1)")
  elfutils 0.152 1.mga1 x86_64
  gcc-c++ 4.5.2 4.mga1 x86_64
  gettext 0.18.1.1 2.mga1 x86_64
  lib64gettextmisc 0.18.1.1 2.mga1 x86_64
  lib64unistring0 0.9.3 4.mga1 x86_64
  libstdc++-devel 4.5.2 4.mga1 x86_64
  libtool-base 2.4 3.mga1 x86_64
  m4 1.4.16 1.mga1 x86_64
  perl-List-MoreUtils 0.300.0 3.mga1 x86_64
  perl-Module-ScanDeps 1.20.0 1.mga1 noarch
  python-pkg-resources 0.6.14 7.mga1 noarch
  python-rpm 4.8.1 10.mga1 x86_64
  rpm-build 4.8.1 10.mga1 x86_64
  rpm-mageia-setup-build 1.133 1.mga1 x86_64
  rpmlint 1.2 1.mga1 noarch
(medium "Core 32bit Release (distrib31)")
  autoconf 2.68 1.mga1 noarch
  automake 1.11.1 3.mga1 noarch
  perl-JSON 2.510.0 1.mga1 noarch
  perl-YAML 0.730.0 1.mga1 noarch
  python-enchant 1.6.5 1.mga1 noarch (suggested)
  python-magic 5.06 1.mga1 noarch
  spec-helper 0.31.5 2.mga1 noarch
35MB of additional disk space will be used.
9MB of packages will be retrieved.
Proceed with the installation of the 22 packages? (Y/n) n

If i disable the 32bit repositories, it works as expected.

This was also the case with mozilla-thunderbird-de package, which is actually noarch, but present in both repos. It offered to install this twice (x86 & x86_64 noarch), then downloaded both, but installed only one. Just a pity i don't have logs of that.

Repositories were setup with drakrpm-edit-media, choosing a specific mirror for all repositories. Of the 32bit repositories, only Core_Release and Core_Updates are activated.

[Doktor5000 (doktor5000)]

Well, it seems the problem occurs only with noarch packages which are present for both architectures, x86 and x86_64.

[Dmorganec (dmorganec)]

this is noarch packages so this doesn't matter if they come from 32 bit or 64bit repo.

[J-manuel (j-manuel)]

but if we have a local repo in x86_64 and ftp mirror for i586, it search on the ftp

[Ahmad Samir (ahmad.samir)]

True, I've seen this too only with noarch packages, urpmi seems to prefer to get them from i586 repos even if the same package(s) is available in the x86_64 repos.

However, it doesn't matter much, the noarch package is the same in all of the repos.

[Doktor5000 (doktor5000)]

Hmmm, so should i set this to RESOLVED INVALID or leave it open?

[Doktor5000 (doktor5000)]

Whoops. Seen to late that it is RESOLVED FIXED. Was that me accidentaly or doesn't mageia bugzilla send mails about bug status changes?

[J-manuel (j-manuel)]

you must be in the cc list for that

[Ahmad Samir (ahmad.samir)]

It's wontfix (just a nitpick).

[Doktor5000 (doktor5000)]

(In reply to comment #7)
> you must be in the cc list for that

I'm the reporter. Why should i add mself to the CC list? Or is this some strange kind of new feature or misconfiguration? All bugzillas that i have used send also status notifications, no matter if you're reporter or only CC'ed.

[Ahmad Samir (ahmad.samir)]

(In reply to comment #9)
> (In reply to comment #7)
> > you must be in the cc list for that
>
> I'm the reporter. Why should i add mself to the CC list? Or is this some
> strange kind of new feature or misconfiguration? All bugzillas that i have used
> send also status notifications, no matter if you're reporter or only CC'ed.

AFAIK we didn't change anything regarding the email preferences in bugzilla, we're using the upstream defaults.

Please check your prefs at https://bugs.mageia.org/userprefs.cgi?tab=email , particularly the "Reporter" column.

[J-manuel (j-manuel)]

Well for me it's a real bug.

[Sander Lepik (sander85)]

(In reply to comment #11)
> Well for me it's a real bug.

?!

[J-manuel (j-manuel)]

(In reply to comment #12)
> (In reply to comment #11)
> > Well for me it's a real bug.
>
> ?!

?! = why ?

I have a local mirror with only the x86_64 repository aka core, nonfree and tainted with (release, updates, updates_testing, backports, backports_testing)
And and online reposity for i586 core (release, updates, updates_testing, backports, backports_testing) .

If I install a x86_64 package who require or suggest a noarch package, the noarch package is not pick on my local repo but on the online one.

So why should I again download a package that I have already on my local repo ? (noarch on i586 and x86_64 are the same)

[Grenoya (grenoya)]

moreover, by pointing on 2 different repositories (local and remote) you can encounter synchronisation problems...

[Thomas Backlund (tmb)]

That is indeed a bug.

I guess urpmi sorts arches with the requested package alphabetically so i586 gets used before x86_64.

urpmi knows to prioritize local media as in cd/dvd/harddisk, but when you add network media, it cant easily decide what is local and what is remote

I wonder if the urpmi --strict-arch flag would help on x86_64 even if rpms are noarch.

A "workaround" is of course to keep the i586 medias disabled, and only enable them when needed.

[Doktor5000 (doktor5000)]

(In reply to comment #13)
>
> If I install a x86_64 package who require or suggest a noarch package, the
> noarch package is not pick on my local repo but on the online one.

Well, actually this is related, but a slightly different bug, IMHO.
AFAIK urpmi always prefers local packages over remote ones. This can be easily seen if after a default installation you don't remove the CD/DVD repos, and want to install packages. It will always want that CD/DVD even if the packages are also in the online repos. So there must be something that's buggy about this behavior.

[Doktor5000 (doktor5000)]

(In reply to comment #15)
>
> urpmi knows to prioritize local media as in cd/dvd/harddisk, but when you add
> network media, it cant easily decide what is local and what is remote

Can a "local" mirror (but only accessible over network) be marked as such somehow in urpmi.cfg to make this known to urpmi, like in Manuels case?

[Anssi Hannula (anssi-hannula)]

(In reply to comment #15)
> I wonder if the urpmi --strict-arch flag would help on x86_64 even if rpms are
> noarch.

--strict-arch is the default on x86_64.

[J-manuel (j-manuel)]

So this one is a duplicate of bug 1546 ?
(or my bug :) )

[Thomas Backlund (tmb)]

(In reply to comment #19)
> So this one is a duplicate of bug 1546 ?
> (or my bug :) )

Nope.

your bug is about missing local media -> should switch to external mirror

this bug is about pulling noarch rpms from x86_64 (local) media before trying external media

[Jeff Johnson (n3npq)]

tracked at https://bugs.launchpad.net/rpm/+bug/913208

[Denis Silakov (dsilakov)]

Hm, are bug watchers alive? The upstream bug was mark as fixed long ago.

As for the bug itself, there is no issue with selecting noarch package from 32bit repository. Though creating a separate noarch repo would allow to avoid such confusions.

[Jeff Johnson (n3npq)]

Mageia has likely prevented bug watchers from working: I am likely "censored"
somehow at Mageia since the last retrieved comment was my tracking notification.

Meanwhile I have less interest in how Mageia resolves a "bug" than in the context
of what users consider a problem with RPM based software installation. In this case
the arbitrariness of using "noarch" etc as a categorical organization in mirror hierarchies.