Bug 1003593 - [RFE] improve yum to support $autoarch macro in yum repo files
[RFE] improve yum to support $autoarch macro in yum repo files
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: yum (Show other bugs)
6.4
Unspecified Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: packaging-team-maint
BaseOS QE Security Team
: FutureFeature
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-09-02 08:57 EDT by Frantisek Reznicek
Modified: 2015-11-15 20:14 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-03-27 11:22:03 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Frantisek Reznicek 2013-09-02 08:57:26 EDT
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:
Comment 2 James Antill 2014-03-27 11:22:03 EDT
 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.

Note You need to log in before you can comment on or make changes to this bug.