Thank you for the report.
Unsure where to assign it. Start with mageiaTools; could it be rpmstack?

Assignee: bugsquad => mageiatools

I "think" this only happens with grub2 spec because of it's uggly packaging layout

because of this:

Source111:      mageia.macros
%include %{SOURCE111}

I meant:
Source1:        grub.macros
%include %{SOURCE1}


but all those %include and their contents will screw spec parsing

Yes, the problem is that urpmi has no idea where those files are.
It expects them in _sourcedir which would be /root/rpmbuild/SOURCES.

Tools like bm  will redefine _topdir so that rpm finds everything but I can't think of a clean way to achieve it with urpmi.

A workaround is to to bm -s --nodeps + urpmi SRPMS/*

CC: (none) => pterjan

(In reply to Florian Hubold from comment #0)
> Seems urpmi behaviour changed regarding --buildrequires when trying to
> install them from a .spec file, or the parsing for .spec has changed. Seems
> urpmi is trying to parse/stat all the Sources instead of just installing all
> BuildRequires. ...

Hello, Florian Hubold.
A long time ago, I wrote a script to make it easier to install "BuildRequires" directly from *.spec, who "understands" the "Provides". In addition to Mageia, the script understands *.spec's from Fedora, which is useful for migrating packages. If the Administration allows it, I will leave a link here just in case, since the topic is about this. Florian, perhaps it will be an addition to your collection of scripts.

https://github.com/AKotov-dev/deps

Sincerely,
Alex

CC: (none) => alex_q_2000

Thanks Alex, this is not about how to install buildrequires, I can easily install them via the src.rpm or manually by simply looking for all BuildRequires.

(In reply to Pascal Terjan from comment #5)
> Yes, the problem is that urpmi has no idea where those files are.
> It expects them in _sourcedir which would be /root/rpmbuild/SOURCES.
> 
> Tools like bm  will redefine _topdir so that rpm finds everything but I
> can't think of a clean way to achieve it with urpmi.

one way could be to parse pwd of spec file, if it is "SPECS", check if it has a SOURCES at same level and set _topdir accordingly...

but otoh I think only grub2 is (ab)using the %include, so it would be easier to fix that spec and drop all the useless cruft in it...

I disagree.
First that's not the only package to use %include
Second, %include is a standard feature of modern rpm, we've to live with it.
So we can patch urpmi to handle that case…

@tv:

For completeness sake, Neal mentioned to me that this works just fine with dnf via

sudo dnf builddep -D "_topdir %(pwd)" SPECS/grub2.spec

Maybe some of the spec parsing logic can be adapted and fixed in urpmi ?

There is no specific logic in dnf, defining _topdir is what is needed, but it is not very user friendly to require the user to do so...

One suggestion in comment #8 was to try to detect if it is the parent directory of the one holding the .spec file and set it.

(In reply to Pascal Terjan from comment #11)
> There is no specific logic in dnf, defining _topdir is what is needed, but
> it is not very user friendly to require the user to do so...
> 
> One suggestion in comment #8 was to try to detect if it is the parent
> directory of the one holding the .spec file and set it.

It is deliberately *not* part of DNF because it's *very* dangerous to allow mutations for RPM settings from the CLI like that in a global context. The builddep subcommand is a plugin that implements a very constrained way to mutate RPM settings to *just* handle spec parsing and revert it before passing on the result to libdnf to set up the transaction to install the packages without those mutations affecting librpm.

CC: (none) => ngompa13