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
https://yselkowitz.fedorapeople.org/steam-i686/view--view-fedora-rawhide-i686.html

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 Only10963 RPMs
4491 SRPMs
------------------------------
Base Buildroot
83 RPMs
58 SRPMs
Buildroot level 1
2267 RPMs
947 SRPMs
Buildroot level 2+
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).
```

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@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Reply via email to