| Summary: | urpmi wants to download noarch from the 32bit repository on a x86_64 host | ||
|---|---|---|---|
| Product: | Mageia | Reporter: | Florian Hubold <doktor5000> |
| Component: | RPM Packages | Assignee: | Thierry Vignaud <thierry.vignaud> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | Low | CC: | dmorganec, grenoya, mageia, n3npq, tmb |
| Version: | Cauldron | ||
| Target Milestone: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Source RPM: | perl-URPM | CVE: | |
| Status comment: | |||
|
Description
Florian Hubold
2011-06-05 14:43:40 CEST
Well, it seems the problem occurs only with noarch packages which are present for both architectures, x86 and x86_64. this is noarch packages so this doesn't matter if they come from 32 bit or 64bit repo. Status:
NEW =>
RESOLVED but if we have a local repo in x86_64 and ftp mirror for i586, it search on the ftp 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. Hmmm, so should i set this to RESOLVED INVALID or leave it open? Whoops. Seen to late that it is RESOLVED FIXED. Was that me accidentaly or doesn't mageia bugzilla send mails about bug status changes? you must be in the cc list for that It's wontfix (just a nitpick). Resolution:
FIXED =>
WONTFIX (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. (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. Well for me it's a real bug. Status:
RESOLVED =>
REOPENED (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) moreover, by pointing on 2 different repositories (local and remote) you can encounter synchronisation problems... CC:
(none) =>
grenoya 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. CC:
(none) =>
tmb (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. (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? (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. So this one is a duplicate of bug 1546 ? (or my bug :) ) (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
Thierry Vignaud
2012-01-06 18:49:53 CET
Priority:
Normal =>
Low I think this bug and bug #4322 would be better fixed by spliting noarch packages in their own repository
Thierry Vignaud
2012-02-07 19:33:45 CET
Source RPM:
urpmi =>
perl-URPM Fixed Status:
REOPENED =>
RESOLVED Note sure I will push this as an update for mga1 though. Version:
1 =>
Cauldron |