RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1003593 - [RFE] improve yum to support $autoarch macro in yum repo files
Summary: [RFE] improve yum to support $autoarch macro in yum repo files
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: yum
Version: 6.4
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Packaging Maintenance Team
QA Contact: BaseOS QE Security Team
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-09-02 12:57 UTC by Frantisek Reznicek
Modified: 2015-11-16 01:14 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-03-27 15:22:03 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Frantisek Reznicek 2013-09-02 12:57:26 UTC
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 15:22:03 UTC
 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.