On 05. 05. 21 10:15, Panu Matilainen wrote:
> 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.
I understand that point of view, but maybe deprecating stuff isn't that
complex?
It's not about complicated per single change, it's about collapsing
under the weight of backwards compatibility if we start worrying about
and going through deprecation process for every undocumented behavior
and interface that people may have discovered.
I've tried to do it in
https://github.com/rpm-software-management/rpm/pull/1668
>> 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.
I've tried to add an explicit -n option to %autopatch in the PR linked
above to make it less silly.
What do you think?