The current logic ALWAYS uses data for the current system. This is wrong. It is impossible to set $arch to armv7hnl or armv7hl because it's not that easy to fake /proc/cpuinfo. I think the arch parts should be moved out of dnf/conf/substitutions.py and into dnf/yum/config.py Setting arch should set the corresponding basearch automatically (makes configuration easier). Should I submit a patch?
Please send your use case first. Why do you need to install arch-incompatible packages? That's an action you should not take unless you really know what are you doing. So far I have heard just about a few rel-eng use cases but addressing them will more likely happen in the underlying libraries.
Created attachment 990366 [details] Set arch and basearch through YumConf I want to install arch-incompatible packages in another root. It would be a good idea to support this in the dnf cli because it's very easy to use, for example in shell scripts. Using setarch does not always work (armv7hnl and armv7hl). dnf --setopt arch=i686 --installroot=... This would also make setting arch and basearch a bit easier: conf.substitutions['arch']=arch conf.substitutions['basearch']=dnf.arch.basearch(arch) can become: conf.arch=arch
Do I understand it correctly that the install root is mounted from another system running on ARM?
Mounted on the other system via NFS or copied to it. Most systems will be i686 or x86_64 but it would be good to support all architectures. I think the setarch approach is ugly.
I think inspecting the rel-eng use case for this feature is the right next step. Perhaps there is some overlap between the two, in which case it might be better to address the specific use case rather than doing some general implementation.
This bug appears to have been reported against 'rawhide' during the Fedora 22 development cycle. Changing version to '22'. More information and reason for this action is here: https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora22
This can be useful not only in #comment2 case. As copr repositories can not generate multilib packages for x86_64, it will be useful to set arch temporary to i686, to install i686 version of some library.
Mirek, how mock changes arch in DNF? through variables?
mock use this code: _libc = ctypes.cdll.LoadLibrary(None) _libc.personality.argtypes = [ctypes.c_ulong] _libc.personality.restype = ctypes.c_int _libc.unshare.argtypes = [ctypes.c_int,] _libc.unshare.restype = ctypes.c_int personality_defs = { 'x86_64': PER_LINUX, 'ppc64': PER_LINUX, 'sparc64': PER_LINUX, 'i386': PER_LINUX32, 'i586': PER_LINUX32, 'i686': PER_LINUX32, 'ppc': PER_LINUX32, 'sparc': PER_LINUX32, 'sparcv9': PER_LINUX32, 'ia64' : PER_LINUX, 'alpha' : PER_LINUX, 's390' : PER_LINUX32, 's390x' : PER_LINUX, } if per is None or per in ('noarch',): return if personality_defs.get(per, None) is None: return res = _libc.personality(personality_defs[per]) and then call normally (i.e. as subprocess) dnf command.
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
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.
I think that new conf options ``arch`` and ``basearch`` in dnf-2.6.2-1 should provide requested functionality. If not, please reopen the bug report.