On Tue, 2024-02-27 at 16:14 +0100, Dominique Leuenberger wrote:
Factory has (had) a total of 2088 packages affected by %patchN on Feb 20 2024
This morning, Factory had 1099 packages affected. Progress is pretty good for something that will only break on us in a year (or half a year, should we really get RPM 4.20 that early into Factory) (I think, taking all pending SRs into account, we are like 80% done with this change)
As I said in my first post in this thread, I appreciate the work you're doing.
There are very interesting things on the horizon for RPM/Spec (like dynamic spec generation, doing away with a lot of boilerplate)
Just as an example: https://github.com/rpm-software-management/rpm/issues/1087
Interesting? Certainly. Will it make package maintainers' lives easier? No, at least not in the foreseeable future for anyone who has to maintain compatibility for LTS releases like SLE.
To not stay in the way of the future, the past sometimes needs to be forgotten.
I still fail to see why this breakage was necessary to enable future enhancements.
I can't help myself, I find it annoying that people break backward compatibility light-heartedly like this, "because they can". I wish more upstream maintainers took API compatibility as seriously as Linus does.
RIGHT! The kernel is known to not break API /s (the only thing they commit to is user space - but definitively not the kernel API. Ask nVidia :P - or the virtualbox maintainer )
I think you understood well that I was referring to the user space API, not kernel-internal APIs. Support for basic macros is an external API as far as rpm is concerned. Regards, Martin