On 25. 05. 20 18:33, Tomas Orsava wrote:
On 4/19/20 4:55 PM, Miro Hrončok wrote:
> 4) Make it so that for given arguments, the macro will only expand to
> something once per build. Hence when you use it with package name, the
> automatic provides won't re-add the same provide again. This also means you
> cannot have 2 different (sub)packages provide the same name-version-release,
> but that shall be very very very uncommon need and can always be workarounded
> somehow if needed.
I thought multiple identical provides were just unified and didn't pose a
problem. So what is the reason to focus on this once-per-build expansion?
Not if one if manual and one from a generator. See:
https://github.com/rpm-software-management/rpm/issues/1166
> 7) Support arbitrary names. Only provide the given name and
nothing else if
> not "recognized".
Given the limitations, I agree with this choice.
What limitations?
> Usage example:
>
> %package -n python3-setuptools
> %python_provides python3-pkg_resources
>
> Resulting provides:
>
> python3-setuptools = 46.6.6-6.fc33
> python-setuptools = 46.6.6-6.fc33
> python39-pkg_resources = 46.6.6-6.fc33
> python3-pkg_resources = 46.6.6-6.fc33
> python-pkg_resources = 46.6.6-6.fc33
> python39-pkg_resources = 46.6.6-6.fc33
What provides the names `python-setuptools`
The generator.
and `python39-pkg_resources`?
%py_provides python3-pkg_resources
(Note that it is python3.9-pkg_resources now.)
From
the code [0] it looks like the current rawhide implementation of %py_provides
doesn't.
On the other hand, it might be a good idea to also provide the names for the
given %subpackage name (with an option to disable this). In that case, the
macros should also without any parameters at all.
I don't get this part, sorry.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok