Red Hat Bugzilla – Bug 1003593
[RFE] improve yum to support $autoarch macro in yum repo files
Last modified: 2015-11-15 20:14:53 EST
Description of problem:
[RFE] Improve yum to support $autoarch macto in yum repo files.
There are ongoing issues with yum repo file flexibility around allowed variables $arch / $basearch.
In the past yum repository URLs followed $basearch values (i386, x86_64, ...), since F11/el6 package maintainers started to use i686 instead of i386 which makes some sense.
Yum does not fully follows/supports that change since that moment. The logical answer to the change should be use of $arch instead of $basearch, unfortunatelly $arch is not replaced by os.uname() string as documentation claims.
(This is discussed and uncovered by bug 1003554)
Knowing all of that you will end up with following matrix:
$basearch i386, x86_64, ...
$arch i686, amd64/ia32e, ...
Above situation is not what user may expect from enterprise level software I believe.
I thus propose to add additional yum repo variable called '$autoarch'
The idea behind '$autoarch' is to let yum find appropriate value from list of possible substitutions (priority list, by default defined by yum, changeable by user). This would allow to use $autoarch and always get to the packages (regardless of actual subdir name packager used).
So in more detail:
* yum repo files allow $autoarch variable/macro
* yum to define (reasonable) default ordered list of possible $autoarch values
* 32bit arch: ['i686', 'i386']
* 64bit arch: ['x86_64', 'ia32e', 'amd64']
* yum to maintain per repo URL one concrete $autoarch variable based on existence valid 'repodata' subdir in constructed path, first matches, others are ignored.
* it is key that there may be multiple yum repositories with different $autoarch values (even in scope of single yum repository file)
* user should be able to specify custom ordered list of possible $autoarch values
* this feature is optional as requires to specify list of architectures which goes the opposite direction of the main idea
* defined just for feature completeness
* definition of the ordered list of possible $autoarch value should be part of a repository
* yum clean all should be able to throw away all the $autoarch values
Version-Release number of selected component (if applicable):
Steps to Reproduce:
Unable to achieve layered-product install among el5-7 with single yum repository file.
Enhanced yum repository file syntax to support $autoarch to be able to install any product among el5-7 using single yum repository.
If you want a new arch variable, you really need to discuss it upstream. Including what you want the arch to represent and how/etc. We have more than just i386/x86_64 arch support in yum, or a start.
However I think you might be confused, just because Fedora has moved to .i686 only doesn't mean you can't still use i386 as the basearch (that's what it is!). So having some variable that outputs i686/x86_64 would be pretty weird.