Dne 25. 02. 21 v 16:34 Fabio Valentini napsal(a):
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.
Would it be possible to use rich dependencies instead? E.g. ~~~ BuildRequires: (Qt5WebEngine %ifnarch pp64le) ~~~The above certainly wont work, but having the generated dependencies to correspond with source dependencies would be worth of the effort.
Vít
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
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ 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
