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:
> > == 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
> > 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.
devel mailing list -- email@example.com
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines