[prev in list] [next in list] [prev in thread] [next in thread] 

List:       fedora-devel-list
Subject:    Re: i386 leaf report
From:       Fabio Valentini <decathorpe () gmail ! com>
Date:       2023-09-27 21:51:45
Message-ID: CAB-QmhQ6+qFvfy6HiJhoofE2jgXFKzyd5Gp4z86jXMjQ2QM9JA () mail ! gmail ! com
[Download RAW message or body]

On Wed, Sep 27, 2023 at 11:32 PM Jerry James <loganjerry@gmail.com> wrote:
>
> Figuring out whether a given package is a leaf for i386 is a pain in
> the neck when done manually.  How about we have a computer figure it
> out for us?
>
> Those of you who run regular reports, what would it take to run a
> report every week or two that lists every package X such that:
> 1. X has no ExcludeArch field that expands to a value including "i386";
> 2. X has no ExclusiveArch field that expands to a value not including "i386";
>    and
> 3. For every package Y that BuildRequires or Requires X or any of its
>    subpackages:
>    A. Y has an ExcludeArch field that expands to a value including "i386"; or
>    B. Y has an ExclusiveArch field that expands to a value not including "i386".
>
> Bonus points if the report can take a list of packages to exclude.
> That way, over time we can figure out which packages we really want to
> build for i386 and drop them from the report.  When the report lists 0
> packages, we have reached nirvana.
>
> I'm willing to put in some work to write such a report, but have no
> clue how to get started.  If someone can point me in the right
> direction, I can take a stab at it.

I've thought about doing something like this, but it's more difficult
to get right than it looks like at first glance.

Problem 1: You cannot rely on repository metadata. Since koji throws
away SRPMs from all architectures except for one random one,
architecture-specific BuildRequires are not reliably represented in
our repository metadata.
Problem 2: So long as noarch packages are also randomly scheduled to
sometimes be built on i686, all noarch packages also need to be
included in the analysis for what things need all their dependencies
available on i686.
Problem 3: Imagine a situation where a package that is still required
on i686 adds a new dependency on a package (and its dependency tree)
that has already been removed from i686. What needs to happen in this
case? Do we possibly need to handle bootstrap problems if too many
things are dropped?

- Problem 1 can be worked around by processing spec files directly
(ew), or by parsing buildroot information that is stored for all koji
builds (available via koji API).
- Problem 2 is, I think, being worked on by releng / fedora-infra, so
that in the future, it might be possible to exclude i686 builders when
scheduling noarch builds.
- Problem 3 might be too hard to solve, and might also not be a (big)
problem in the timeframe where we still need to care about i686
packages.

However, for parsing spec files, there's also the question of ...
which spec files need to be parsed?
Those committed into the rawhide branch? Those might not have been
built yet. Those from the SRPM associated with the last tagged koji
build? Not sure how feasible it is to get those efficiently.

Fabio
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-leave@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

[prev in list] [next in list] [prev in thread] [next in thread]