On 5/11/24 01:04, Kevin Kofler via devel wrote: > Florian Festi wrote: >> We have an even easier solution for you: You can just run the script at >> [3] with -n on your own spec files to get them changed to the %patch N >> variant. If you do that right now they will not break nor will they be >> touched during the mass change. >> >> As I said the %patch -PN syntax is the one with the best compatibility - >> reaching back into the dark ages. I am not advocating for people to use >> it. Anyone is free and encouraged to move to something more modern - >> before or after the change. We are using this variant so spec files >> continue to work on older distributions and the chance of breakage is >> minimized. This way packagers that don't care don't have to. > > What I do not understand is why RPM is discontinuing the most commonly used > syntax and breaking hundreds of specfiles. This also leaves us with only the > choice between a backwards-incompatible syntax (added only in RPM 4.18) and > an ugly and redundantly verbose syntax (the -P syntax). And even the modern > syntax is 1 character (space) longer for every patch. The shortest syntax > was the one being dropped. I am glad you asked. The short answer is the %patchN instances are not a proper macros and we no longer can have that. The long story is that the spec parsing code is old, weird and is one of the few places in RPM that have not seen major renovations in the last two decades - until now. We have also put a lot more stress on that code with all the language specific macros and lua scripts, extended debuginfo support, dynamic spec parts, the new build scripts, ... So a lot of the weirdness and corner cases that were "fine" for "normal" specs are now showing up more and more. Expanding the %patchN syntax required a whole separate parse and expand run that was separate from the macro expansion. This led to subtle semantic issues wrt expansion order. It also made %prep special and %patchN only worked in there. %patch otoh (now) is a regular (though internally implemented) macro that is expanded with other macros and though can be used in other macros and expressions. This is only one of many issue with the parsing (and building) code and we are actively working on disentangling the mess. For most things packager won't notice unless they do more complicated things where these semantic details matter. But the %patchN syntax is something that is just not worth preserving. It does not fit into the overall macro frame work and should not have been added in the first place. I also have a hard time seeing how adding a single space per %patch line is overburdening packagers. Florian -- _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-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/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
