So I went and looked at the proposal for i686 support and one of the possible solutions was to use the content resolver to work out what would need to be rebuilt for i686 or at least to get an idea of what might need to remain in i686 builds.
I took a stab at it and got a pull request together for the two workloads being talked about. https://github.com/minimization/content-resolver-input/pull/1439
Yaakov Selkowitz was kind enough to look over the PR, make some suggestions and then try to run the workload on his home system. He then uploaded the results (it takes multiple hours) to
The first thing which was what Troy Dawson talked about in the first comment is that content resolver doesn't know how to separate out what is i686 from x86_64. This means the dependency chain is currently much larger than it needs to be but it won't be clear how large it needs to be without some sort of work to make content resolver multi-arch aware.
The second thing is that the list of packages could potentially be a lot larger than most people expect. There are currently 3 levels of buildroot that the system finds:
Buildroot Only
10963 RPMs4491 SRPMs
Base Buildroot
83 RPMs
58 SRPMs
83 RPMs
58 SRPMs
Buildroot level 1
2267 RPMs
947 SRPMs
2267 RPMs
947 SRPMs
Buildroot level 2+
8613 RPMs
3486 SRPMs
8613 RPMs
3486 SRPMs
The initial package needs around 83rpms to build, but to build those you need at most 4408 others. I will include Mr Selkowitz's additional comment https://github.com/minimization/content-resolver-input/pull/1439#issuecomment-3013672223
```
After my review above, I noticed more things that I didn't cover in my initial tweaks, so I reran this locally (which took ~3.5 hours on my machine) and have synced the results out to https://yselkowitz.fedorapeople.org/steam-i686/view--view-fedora-rawhide-i686.html, but the difference is minimal.
CR would need some improvements in order to get more accurate results wrt a limited multilib tag and the packages that would need to be therein (as the buildroot here is clearly inflated). Nevertheless, I think the results show that a limited opt-in multilib approach would still be far larger than otherwise necessary. Furthermore, that would still force some degree of multilib support, which contradicts some of the goals of the original proposal. Therefore, I would suggest further investigation into alternatives instead (e.g. -m32 variants or mingw-style cross-compiling).
```
CR would need some improvements in order to get more accurate results wrt a limited multilib tag and the packages that would need to be therein (as the buildroot here is clearly inflated). Nevertheless, I think the results show that a limited opt-in multilib approach would still be far larger than otherwise necessary. Furthermore, that would still force some degree of multilib support, which contradicts some of the goals of the original proposal. Therefore, I would suggest further investigation into alternatives instead (e.g. -m32 variants or mingw-style cross-compiling).
```
I wonder if this shorter list could be made to make a list of 'its ok to exclude i686' in. The upstream for the content-resolver code is https://github.com/minimization/content-resolver if anyone wants to look at helping improve it.
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren-- _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
