When running 'dnf builddep' against a .src.rpm, dnf, by default, should extract the specfile and run builddep against it. The current behavior of running "dnf builddep some.src.rpm" should be available via an option. Please see bug#664427 and bug#771938 for more details and the background of this request. Some more comments from Panu: (11:51:39) Panu: pulling the dependencies from an src.rpm directly is a perfectly sane and reasonable thing to do, for example the buildsystem uses that (11:52:33) Panu: the src.rpm can reflect things like --with/--without options and defines passed to rpmbuild when constructing the src.rpm (11:52:58) Panu: if you just extract the spec from the src.rpm and parse it, such things will be gone (11:53:29) Panu: that doesn't affect fedora, but one should be aware of it (11:55:19) Panu: also getting dependencies out of src.rpm doesn't require parsing and executing arbitrary content from unverifiable source (the spec) (11:55:46) Panu: I'm not telling not to implement it (11:55:56) Panu: just that you should be aware of the subtleties involved (11:56:57) Panu: one possibility might be for dnf builddep to default to extract and parse the spec, but have an option to use the src.rpm deps directly (11:57:40) Panu: that allows people who know what they're doing (eg the buildsys) to continue doing what it does with the option, while others get "mostly just works" behavior (12:05:26) vmukhame: I'm not quite sure why you call the spec an unverifiable source (12:06:14) vmukhame: and anyway, dnf builddep already can run against spec, although it's unverifiable (12:06:19) Panu: sure (12:07:03) Panu: a standalone spec is unverifiable, one from a known-good signed src.rpm of course is much better (12:08:37) vmukhame: also, how bad is it to ignore those options and defines from a user's POV (12:09:42) Panu: well, it breaks certain previously workable settings (12:10:09) Panu: like said, fedora (and rhel) packages are not allowed to rely on anything like that (12:10:53) vmukhame: "are not allowed to rely" means "should work fine even if we ignore them"? (12:11:31) Panu: packages in fedora and rhel must build as they are without any options, so yes (12:14:19) Panu: anyway, the point is there are reasons for not wanting to extract and parse the spec from an src.rpm, and that case should be preserved
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.