Le mardi 30 juin 2020 à 21:45 +0200, Igor Raits a écrit : > On Tue, 2020-06-30 at 15:19 -0400, Ben Cotton wrote: > > > > https://fedoraproject.org/wiki/Changes/Patches_in_Forge_macros_-_Auto_macros_-_Detached_rpm_changelogs > > > > == Summary == > > > > redhat-rpm-config will be updated to add patching support to forge > > macros, a plug-able framework to register macros to execute in > > specific sections, and rpm changelogs in detached files. > > > > == Owner == > > * Name: [[User:nim| Nicolas Mailhot]] > > * Email: <nicolas.mailhot at laposte.net> > > > > == Detailed Description == > > > > This is a system-wide change because all packages build with > > redhat-rpm-config, but it only concerns packages that opted to use > > this part of redhat-rpm-config (users of forge, fonts and go > > macros). > > > > It was driven first, by the need to make the underlying macro > > infrastructure robust enough to package Go modules, and second, by > > an > > unfortunate rpm 4.15 regression that proved it was foolish to > > depend > > on rpmbuild to parse Tags in anything except canonical order. > > I think this would be already at least 30 times we mentioned that RPM > works as expected and the bug was just in the spec files that relied > on Name being parsed before expanding ~/.rpmmacros. Yes, rpm broke existing specs and you insisted it was normal it broke them and the 10+ years during which the pattern they used worked was an anomaly. You told me nothing would be fixed, and I just had to generate tags in the exact undocumented order you wanted them generated, and that you did not care about my problems (to the point, you proposed reverting whole parts of the distribution to the level they were years ago just so you did not have to deal with them). So here is the code that does exactly that. You got your wish, it caused me a lot of work and pain to implement, get out of your defensive mode, people are not doing things to make you miserable they are doing things to solve their own problems. All the things you pretend discovering today have been hashed and re- hashed to death with rpm upstream (to the point, Panu once dismissed a ticket, stating I had already asked the same thing many times and the answer was still no). So now I solved *my* packager problems at the macro level with no rpm maintainer help whatsoever and I don’t care if rpm maintainers suddenly feel they could do better. I spent litterally decades asking them to look at those things, and they did not care (Florian excepted, thank you Florian). > > > A packager that needs custom processing can add custom code above > > or > > bellow the various `%auto_foo` calls, and check with `rpmspec -P` > > that > > the result does what he wants it to do. For obvious reliability > > reasons injecting custom code in the middle of an `%auto_foo` > > sequence > > is not allowed. > > What about rpmdev-bumpspec, vim plugin and such tools adoption that > expect Version/Release/%changelog to be present in spec? That’s why a second change deals with autobumping. That’s why I objected vigorously when you and Panu told me two months ago to generate tags values instead of pointing out that changes in Tag evaluation rules made them useless for my specs. So now everything is generated, and removing the Tag obstruction enabled solving other problems. It was a lot of work I could have done without, but the work is done now, and I *will* use it to its full capabilities, because I did not do this work to make a point, I did it to solve my Fedora packager problems, and it solves them nicely. -- Nicolas Mailhot _______________________________________________ packaging mailing list -- packaging@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to packaging-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/packaging@xxxxxxxxxxxxxxxxxxxxxxx
