On 5/25/20 7:42 PM, Miro Hrončok wrote:
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
Interesting. One thing not mentioned is, does this cause any issues
besides the visual issue of the provide being listed twice?
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?
I was referring to this bit from the other thread:
> we cannot error out with arbitrary package names, so we currently
need to pre-filter the arguments before using them
Did I misunderstand it?
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.
Oh right, I thought you were only talking about the provides from the
macro. Makes sense.
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.
Irrelevant due to my misunderstanding above.
Tomas
[0]
https://src.fedoraproject.org/rpms/python-rpm-macros/blob/master/f/macros.python-srpm#_162
_______________________________________________
packaging mailing list -- packaging@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to packaging-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/packaging@xxxxxxxxxxxxxxxxxxxxxxx
