I'm sorry but I have to strongly object after packaging LLVM for years now.
We use 0%rhel and 0%fedora and while that seems odd at first it is easy to get used to. You most certainly don't want to get me started on %bcond_without which I also got used to and which I also do like to keep. On Mon, Jun 22, 2026 at 6:48 PM Vít Ondruch <[email protected]> wrote: > I for one think that macros such as `%rhel` are antipattern. They > > * prevent innovation > While this is true to some degree I haven't seen much innovation except %autorelease in the past years TBH (and %autorelease/%autochangelog is cool). Maybe it is because innovating is hard but I'd say the problem is more deeply rooted in the slow way that old distros are updating RPM. Most of the newer features are only available on newer distros. And I most certainly want to spend my time more on the upstream project than on maintaining different spec file repos. For LLVM for example we still keep fXX repos around but they look very similar to what is in rawhide. In fact, we can build rawhide and RHEL from the same spec file and we can even build daily snapshots and multiple released versions with one spec file which automatically selects which patches to apply depending on the version of LLVM for example. That said, I wouldn't want to go back. This might not be an innovation in RPM but it is truly making our lives easier than before. Don't blame us for not using cutting edge spec file tech when not providing updates of RPM to RHEL. > * make the spec harder to read > See it blossom :) > > * make the life harder for proven packages doing some (mini-)mass > rebuilds and trying to fix things > It has worked in the past with LLVM so I'm good. > > * tend to age similarly bad to comments in code (granted, there were > recently introduced Packit ELN tests, so it is a bit easier to spot some > breakage) > Definitively not true since we build daily for RHEL using the same spec file that we use for rawhide. - Konrad
-- _______________________________________________ devel mailing list -- [email protected] To unsubscribe send an email to [email protected] 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/[email protected] Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new
