Besides the technical processeeees and procedures to create the RPM’s for a ‘V2’ architecture, there’s some ‘usability’ and ‘functionality’ issues that would probably have to be addressed…
I jumped on the Alma Linux 10 x86_64_v2 bandwagon 2 weeks ago, going thru the process of integrating it into my Kickstart processeees (not much had to be done), package update methodology, and getting my preferred desktop (KDE) to startup and function as it always has (in CentOS 7.9 and Rocky 9.6).
I have been successful at completing those steps, but learned the following along the way…
The “x86_64_v2” release would be limited to whatever has been rebuilt using the x86_64_v2 ‘build process’ and made available via the Rocky repos…
(unless 3rd party entities also begin providing packages for ‘that’ architecture…)
It would be interesting to see if the Alma-Epel-v2 packages (at epel.repo.almalinux.org/) would be usable…
Such that, anyone wanting to configure an Oracle database server, is probably SOL…
Packages that are no longer in the Linux ‘base’ media (nor in Epel) would have to be rebuilt for V2 and made available from ‘somewhere’…
No match for group package “gimp”
No match for group package “qbittorrent”
No match for group package “audacity”
No match for group package “youtube-dl”
No match for group package “libreoffice” (what were they thinking ?)
RPM’s that ‘deal’ with packages (that would now have the x86_64_v2 designation)..
Such as “reposync” which defaults to the “x86_64”, “i386”, and “noarch” package architecture names…
AND does NOT know anything about “x86_64_v2”, though it ‘does’ function if specifically referencing that architecture via the --arch=x86_64_v2
Which requires me to execute “reposync” twice, once to download the ‘standard’ names (basically the ‘noarch’ packages in EL10), and then a second time to obtain the V2-specifically-named packages…
AND !! All package ‘dependencies’ (and ‘provides’ ?) within the SPEC files would have to be modified to refer to the ‘V2’ versions, or they might want to install those packages from the standard ‘x86_64’ repositories (if available, or just result in lotz of ‘dependency not resolved’ errors…)
UNLESS that’s a moot point if you only have ‘V2’ repos configured and enabled…
AlmaLinux DID obtain (most ?) of the packages from EPEL and have created their own repository with rebuilt V2 versions..
You can peruse them HERE: epel.repo.almalinux.org/
This permitted me to install the KDE-Plasma packages, which I somehow got to launch under WayLand…
BUT, there are many other packages needed for ‘enterprise-like’ operations and hardware support, that would need V2 versions:
RPM Fusion: Index of /rpmfusion/free/el/updates/10/
ELrepo: Index of /linux/extras/el10
Apps:
LibreOffice: Download LibreOffice | LibreOffice - Free and private office suite - Based on OpenOffice - Compatible with Microsoft
it appears to be now missing from the base distributions…
Palemoon web browser: Pale Moon - Developer Site - Building Pale Moon: GNU Linux
which could then be added to: Contributed builds