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