Hi Dominique, sorry for dropping the mailing list from the reply, fixed now again. Am Mi., 7. Dez. 2022 um 18:10 Uhr schrieb Dominique Leuenberger / DimStar <dimstar@opensuse.org>:
Sure - it's a wiki and can only benefit from more input.
I added a pro/cons list from my point of view and expanded a bit on the baselibs idea.
The proposal I favor so far is the 'possible option' - i.e allow to build everything (or as much as we want) proprely as a different architecture and get this into rpm/zypp.
I agree that this sounds like the "cleanest" approach, but it uses a hammer for something where not necessarily a hammer is needed, and it has therefore also quite some drawbacks. In addition, this approach has been rejected already previously by rpm upstream, I added the link to that discussion to your wiki page. Also it has a number of downsides, and myself being one of the openSUSE maintainers with the experience on armv6l/armv7l, there is a TON of software that breaks when rpm architecture is not matching the kernel architecture (aka when $(uname -m) != %arch, which is the case for armv7l <-> armv7hl). Maintaining this and getting those fixes upstream is anything but fun, and in this case it only worked because other distributions (fedora, ubuntu/debian) had the same issue, so everyone pushed the various upstreams to accept those patches. And yet, such an assumption is constantly creeping into the code requiring a constant battle of fixes. Also it breaks base interoperability requirements, especially when targetting -v3 and -v4 and thinking about containerized / cloud deployments, where cpu features can change between restart or reboot.
mls has already been lined up and thinks it should be rather easy (for the rpm and obs part)
Yes, that's true for zypper/libzypp. However in the non-openSUSE context of SUSE distributions often 3rd party software is used for systems management, and those need to be adopted for this as well. and many of those have hardcoded assumptions or false assumptions (like $(uname -m) being the rpmarchitecture). ; zypp
itself already has code to treat arch x>y but compatible (i586/i686) - si if we get x86_64<x86_64-v3, we're all set there (plus code to detect what machine you have)
with the downsides that it requires patching of about 1000 packages (%ifarch x86_64 -> %ifarch %x86_64) and not providing coinstallability, meaning you can't have single-installation media/machine images, requiring the user to choose which version works across their data centers and clouds (and hope that they do not use anything like kubernetes that just moves around workload) plus requiring full builds of the tumbleweed distribution (while technically we could build smaller ones for the higher optimized versions, that would mean mix-match deployments on the user side and on our installation medias, increasing size requirements and complexity) Greetings, Dirk