The use-case was to have a `%{pyproject_metadata}` macro like this:
```
%files -n python3-foo
%{pyproject_metadata}
%{python3_sitelib}/foo/
```
The macro would:
* find the built Python dist-info directory, parse the metadata from it,
locate the License-File filed (not yet available) and outpu
The reason I didn't close this offhand was that I'm curious about the use-case,
but apparently forgot to ask about it :) I mean, maybe there is something that
we could do to help the case without making %files parsing more special than
the rest of the spec.
Note that the -f files manifest is ma
Closed #894.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/894#event-2705577119___
Rpm-maint mailing list
Rpm-maint@lists.rpm
Roger that. I've tried :)
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/894#issuecomment-540996257___
Rpm-maint mailing list
That'd require parsing spec %files section without macro expansion, which would
make it completely different from everything else in the spec, and break
legitimate uses. If you take
```
%files
%{one_macro}
%{other_macro}
Those macros might expand to files, or they might expand to new spec sect
