Bug 1210276
| Summary: | RFE: dnf should createfake provides for architecture | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Valentina Mukhamedzhanova <vmukhame> |
| Component: | dnf | Assignee: | rpm-software-management |
| Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | low | ||
| Version: | rawhide | CC: | dmach, Frodox, fweimer, hannsj_uhl, igor.raits, jan.kratochvil, jzeleny, mmraka, nobody, packaging-team-maint, pmatilai, rigault.francois+fed, tim.lauridsen, vmukhame, whydoubt |
| Target Milestone: | --- | Keywords: | FutureFeature, Triaged |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2019-04-11 19:04:20 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Valentina Mukhamedzhanova
2015-04-09 10:30:42 UTC
I strongly disagrre with a change in default behaviour. As Panu stated - parsing deps out of srpm is trivial while doing the same from spec is error prone (mainly because you should evaluate all % macros and %ifs first to get correct list of deps). We can discuss introducing an option for this. The solution doesn't matter, just the use case does. On one hand you are right and parsing spec file is error prone. On the other hand parsing the deps from srpm is inaccurate if the srpm was built on a different arch (see the referenced bug). Bottom line, I like the idea to have a switch for this and let the user decide what does he need. While I do not agree with it I think this Bug is now NOTABUG: You MUST NOT use arched BuildRequires https://fedoraproject.org/wiki/Packaging:Guidelines#BuildRequires_and_.25.7B_isa.7D (In reply to Jan Kratochvil from comment #3) > While I do not agree with it I think this Bug is now NOTABUG: > You MUST NOT use arched BuildRequires > > https://fedoraproject.org/wiki/Packaging:Guidelines#BuildRequires_and_.25. > 7B_isa.7D However, there is nothing mentioned regarding arch-conditional BuildRequires (which is not the same thing). For just one instance, from fedora-logos.spec: %ifarch x86_64 i686 BuildRequires: syslinux-perl, netpbm-progs %endif As the latest fedora-logos .src.rpm was built on ARM, running 'dnf builddep fedora-logos' on my x86_64 machine does not identify syslinux-perl or netpbm-progs to be installed. So it IS still a bug. (In reply to Jeff Smith from comment #4) > However, there is nothing mentioned regarding arch-conditional BuildRequires IMO it is stated by "You MUST NOT use arched BuildRequires.". Also the purpose of that guidelines seems to me exactly to workaround this Bug is not yet fixed. I do not see what other purpose that guideline could have. (In reply to Jan Kratochvil from comment #5) > (In reply to Jeff Smith from comment #4) > > However, there is nothing mentioned regarding arch-conditional BuildRequires > > IMO it is stated by "You MUST NOT use arched BuildRequires.". Also the > purpose of that guidelines seems to me exactly to workaround this Bug is not > yet fixed. I do not see what other purpose that guideline could have. The cases are similar but with subtle differences. The person(s) who wrote "arched BuildBequires" may have meant to refer to BOTH BuildRequires-containing-isa AND ifarch-filtered-BuildRequires, while only giving an example of the former, either because they assumed it was implied or because they didn't recognize a distinction. Or maybe they did recognize a distinction, and meant specifically to ban just BuildRequires-containing-isa. I am preparing to review the cases where ifarch-filtered-BuildRequires are currently used to determine whether it is even realistic to ban them. *** Bug 1298798 has been marked as a duplicate of this bug. *** This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component. Just to clarify: Of course we need conditional, architecture-dependent BuildRequires:. For example, nasm is not available on all architectures. I wonder if a solution to this might be: * Provides: arch = … into something like fedora-release. And then change guidelines to say: Write BuildRequires: (nasm if arch = …) WDYT? Totally missed the last comment... rich dependencies could indeed provide some opportunities to avoid use of spec-level %if-%else conditionals that are the culprit here. fedora-release is a noarch package so it doesn't work here, but on arch-specific packages the arch family is already present in all package provides in the form of foo(<isa>) provides, so where it makes sense to do so, something like "BuildRequires: (nasm if gcc(x86-64))" is already possible. Using gcc/glibc for this has it's own problems though, as it's a multilib package which could cause false positives if both variants are present. I believe that the sanest way of doing this is that DNF would create fake provides like `architecture(x86_64)` so that what Panu describes would work. It looks like that there are not many people that depends on the functionality. The issue is open for about 4 years and even there are comments against implementation of the feature. I am closing in favor of more important issues. |