Bug 1003593

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()[4] 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):
N/A

How reproducible:
N/A

Steps to Reproduce:
N/A

Actual results:
Unable to achieve layered-product install among el5-7 with single yum repository file.

Expected results:
Enhanced yum repository file syntax to support $autoarch to be able to install any product among el5-7 using single yum repository.

Additional info: