Dilemma: -source repository data randomized by koji builder arch

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello everybody,

There's a problem that's been puzzling me for months, since I started
writing the repochecker service (which provides the backend FTI/FTBFS
data for the new packager-dashboard):

There is no correct "source of truth" for BuildRequires / complete
package dependency graphs.

While SRPM *contents* are forbidden from being dependent on their
environment (e.g. Sources or Patches guarded by %ifarch / %if
%fedora), their metadata (RPM headers) will still potentially be
architecture-dependent.

For example: The most frequent case of this is packages disabling
support for Qt5WebEngine on ppc64le and s390x, because it's not
available on those architectures. That means %ifarch conditionals
wrapping the BuildRequires for Qt5WebEngine. But that leads to the
interesting problem of the SRPM file having architecture-dependent RPM
headers.

However, because koji only keeps *one* SRPM file from each build (even
though they have potentially different metadata on different
architectures), and the architecture that one SRPM is generated on is
basically random, the contents of the -source repositories are,
basically, randomized, and unreliable.

The architecture-dependent nature of SRPM files in -source
repositories affects at least those tools and Fedora services:

- dnf builddep (errors when encountering foreign-arch dependencies,
even if they are guarded by %ifarch in the .spec file)
- dnf repoquery and repoclosure produce wrong results
- koschei gets confused by architecture-dependent BuildRequires and
claims "failed dependency resolution" for foreign-arch dependencies

I file an issue with koji asking for a way to get correct metadata for SRPMs:
https://pagure.io/koji/issue/2726

However, I agree that keeping 6 SRPM files with identical *content*
and only different *metadata* is incredibly wasteful. But koji is the
only place in the build pipeline at which the entire and correct
dependency information is available, and it's lost afterwards, because
the rebuilt SRPM files produced by mock on each architecture are
discarded. I don't know if there could be a way to expose an
"srpmdiff" between the SRPM files on different architectures ...

But I'd argue that it's definitely not good that there's currently *no
way* to query BuildRequires *correctly* and *reproducibly* (other than
possibly rebuilding all fedora SRPM files for each target
architecture, but I do not have the resources - nor the desire - to do
that, just to get correct dependency information).

For the repository data that's processed by repochecker (for the
packager-dashboard data), I needed to add hard-coded overrides for
those "false positives", which is definitely not scalable for the
hundreds of different architecture-dependent BuildRequires that exist
in Fedora, but I also don't have a way to find them other than "look
at the .spec file":

https://pagure.io/ironthree/repochecker/blob/master/f/overrides.json

So, if anybody has an idea how we can solve this issue and actually
provide correct repository data, that would be great :(

Fabio
_______________________________________________
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 on the list, report it: https://pagure.io/fedora-infrastructure




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux