Bug 1072972

Thanks, I feel a lot better having this tracked.

Yes its good to have these cases tracked someplace.

Ultimately this data should live in rpm only, with reasonable interfaces for accessing it. Much of this data (but not all) actually exists in rpm, but its not queriable in the sense these cases need.

Panu, do you have plans to implement an interface to access this sometime around F21 GA? (doesn't need to make F21, rawhide is good enough, so we can be migrating the releng tools then).

Otherwise it's going to end up on our side of the field anyway.

I dont have any concrete plans, this is just yet another item that's been on my todo list forever.

We're supposed to be on the same side though :) Since we have to do something about this now, why not target doing it in the right place no matter who actually ends up doing it?

(In reply to Panu Matilainen from comment #4)
> We're supposed to be on the same side though :) Since we have to do
> something about this now, why not target doing it in the right place no
> matter who actually ends up doing it?

Yes of course!

With Dan's help I analyzed the situation around arches. I think it would be the best if this really moved to RPM as RPM already holds the information and we wouldn't like to have yet another copy of the tables (and the logic) in DNF.

For now, DNF will only keep the basearch mapping in a non-api module, solely for the purpose of properly expanding $basearch in .repo files. Once RPM provides the interface we'll use it.

Moving to RPM per comment 2.

This message is a reminder that Fedora 20 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 20. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '20'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 20 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Attached patch and built rpm for testing. This patch adds functions to export architecture information (stored in /usr/lib/rpm/rpmrc) from rpm. It needs testing, I don't know how correct information in rpmrc is. 

Example of using this new functions:

[root@localhost rpm]# python3
Python 3.5.1 (default, Mar  4 2016, 15:21:15) 
[GCC 6.0.0 20160302 (Red Hat 6.0.0-0.14)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import rpm
>>> print(rpm.getCompatibleArches.__doc__)
getCompatibleArches(archname) -- Returns compatible architectures.

For a given archname returns list of compatible architectures i. e. a binary
built for any of compatible architectures must run without problems on
the archname architecture too.
>>> rpm.getCompatibleArches("x86_64")
['x86_64', 'amd64', 'em64t', 'athlon', 'noarch', 'i686', 'i586', 'i486', 'i386', 'fat']
>>> 
>>>print(rpm.getMultiLibArches.__doc__)
getMultiLibArches(archname) -- Returns multilib architectures.

For a given archname returns list of compatible architectures
(see getCompatibleArches()) which are bitwise narrower then the archname
architecture.
>>> rpm.getMultiLibArches("x86_64")
['athlon', 'i686', 'i586', 'i486', 'i386']
>>>
>>> print(rpm.getBaseArch.__doc__)
getBaseArch(archname) -- Returns the base arch for a given arch.
>>> rpm.getBaseArch("i686")
'i386'
>>>
>>> print(rpm.getArchesForBase.__doc__)
getArchesForBase(basearch) -- Returns all arches belonging to given base arch.
>>> rpm.getArchesForBase("i386")
['osfmach3_i686', 'osfmach3_i586', 'osfmach3_i486', 'osfmach3_i386', 'athlon', 'geode', 'pentium4', 'pentium3', 'i686', 'i586', 'i486', 'i386']

Created attachment 1146470 [details]
archive with built rpms for f25

Created attachment 1146472 [details]
patch

Created attachment 1150756 [details]
SRPM with applied patch

Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

We have hit an issue in f25 where anaconda is not resolving the basearch correctly on 32 bit arm, It is coming out as arm not armhfp resulting in installing not working. It would make everyones life easier to have a single source of information as to the basearch and arch to use.

Well, there is a patch and an SRPM above waiting for you to test an comment on...

It builds, data for x86/x86_64/armv7 returns correct data.

I don't believe this is fully solvable for all non-x86
architectures.

The only way to find out if an aarch64 machine can run
armv7 binaries is by examining the datasheets.  Even if you
(wrongly) assume that 32 bit binaries can be run because most
current chips support it, then it still won't work on RHEL b/c
different page sizes.  riscv32/riscv64 is in the same boat.

Also arm <= v7 is a zoo of incompatible arches.

This bug appears to have been reported against 'rawhide' during the Fedora 26 development cycle.
Changing version to '26'.

Could we add the the support for another two use cases?

1. Get the current system's arch.

This could be a new API like detectArch/detectBaseArch or just getBaseArch without any argument passed.

2. Return a list of all known valid arches.

(In reply to Qixiang Wan from comment #18)
> Could we add the the support for another two use cases?
> 
> 2. Return a list of all known valid arches.
Basically, all arches are valid. Even foobarbaz.

There are some differences between what this patch and rpmUtils.arch module do. I have no idea how significant the differences are though.

As an example, getting basearch gives different results (the arches are obtained from rpmUtils.arch.arches).

arch        rpmUtils.arch   rpm
----        -------------   ---
alphaev4    alpha           None
alphaev45   alpha           None
alphaev68   alpha           None
alphaev7    alpha           None
armv5tejl   arm             armv5tejl
armv5tel    arm             armv5tel
armv6hl     armhfp          armv6hl
armv6l      arm             armv6l
armv7hl     armhfp          armv7hl
armv7hnl    armhfp          armv7hnl
armv7l      arm             armv7l
arm64       arm64           None
sparc64     sparc           sparc64
sparc64v    sparc           sparc64


The proposed API seems almost sufficient to remove rpmUtils module dependency from Pungi. Only missing feature is getting current arch or base arch (equivalent of rpmUtils.arch.getBaseArch() without argument).

arm64       arm64           None 

is not a valid combo

This message is a reminder that Fedora 26 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 26. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '26'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 26 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged  change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

In the meanwhile, some effort made has been made by the team to consolidate this arch handling stuff in a separate library called "libparch": https://github.com/rpm-software-management/libparch

However, two things: 1) not sure what the status of that project is (last commit is from 2020) and 2) Python bindings don't seem to be available (yet)

OK, this report is pretty old and the requirements and/or the landscape here might have changed in the meantime.  It also seems that the patch attached here isn't really a proper solution.  I'll close this now.  If you're still interested in this and have some more ideas, please consider opening a discussion at https://github.com/rpm-software-management/rpm/discussions.