On 4/29/21 3:49 PM, Miro Hrončok wrote:
On 29. 04. 21 14:23, Panu Matilainen wrote:
> On 4/29/21 11:58 AM, Miro Hrončok wrote:
>> On 26. 04. 21 12:36, Panu Matilainen wrote:
>>> It's spring, it's raining sleet where I live, and it's also the
>>> season for new rpm in rawhide. As per
>>>
https://fedoraproject.org/wiki/Changes/RPM-4.17.
>>>
>>> The changes to the macro subsystem internals have been quite large,
>>> and while it's supposed to be backwards compatible with changes this
>>> big it'd be foolish not to expect some amount of the unexpected. So
>>> please pay attention, and don't be shy about filing bugs.
>>
>> Another regression found:
>>
>> Convenient public macro %apply_patch removed without warning
>>
https://bugzilla.redhat.com/show_bug.cgi?id=1954999
>>
>
> An intentional change does not classify as a regression in my books.
It is a matter of perspective: A sudden unannounced breakage of
something that worked and appeared as part of the API classifies as
regression in my books :)
> The macro always was just an internal helper and intentionally
> entirely undocumented, just mistakenly lacking the preceding
> undrescores (but then neither of those ever stopped people from using
> "stuff").
It is documented in the macros file (very briefly), like all the other
related macros.
> We can make the change more visible, and we can consider temporary
> patches in Fedora, but %apply_patch is not an interface we want to
> support.
Let's deprecate it maybe in that case?
If it was something that is used by dozens of packages, we wouldn't be
here in the first place. As it is, it's exactly 10 packages in Fedora,
most of which are different versions of Python. So going through a
deprecation process seems over the top.
What is the supported alternative?
%autopatch -m <num> -M <num>
It's a bit silly of course but it IS supported, and easily wrapped in a
local helper as well.
- Panu -