In order to "house" the GPG macros and various other macro-related things which FPC may want to do in the future, I set up and submitted for review the fedora-rpm-macros package. After it passed review and was imported, I added a dependency to redhat-rpm-config.
I have now received a complaint in the review ticket (https://bugzilla.redhat.com/show_bug.cgi?id=1366411) suggesting that the process was not sufficiently not transparent, and also that the package shouldn't exist anyway because anything that's there should just be in redhat-rpm-config.
So I'd like to formally ask FPC to approve the addition of the dependency from redhat-rpm-config to fedora-rpm-macros, so that there's a paper trail.
And to show that I actually thought about it, here are some reasons for preferring a separate package for this:
It has things in it that something close to nobody actually understands. kernel-rpm-macros being a prime example.
Access. If FPC is going to take a rule in approving sets of macros and such (which we appear to be doing), it would be good to have a package that FPC actually "owns" in the pkgdb sense. Currently I think we just use provenpackager privs to make changes to redhat-rpm-config.
And frankly I would like to have a way to do more "experimental" things . I can easily have fedora-rpm-macros spit out a subpackage to hold those. I don't really want to make redhat-rpm-config do that.
If something becomes useful to the point that redhat wants to use it, we can just move the relevant bits up from fedora-rpm-macros to redhat-rpm-config. Or even into rpm itself if other distros want it. I don't see any problem with this, and it's not particularly difficult.
Of course, if FPC decides that it's better to have everything happen directly in redhat-rpm-config, then of course I can do that. And fortunately I can untag things in koji if I screw up badly enough with either package.
Thanks for discussing this! And sorry, I missed this ticket before, it is worth inter-link with related bug :)
Complexity of maintenance of redhat-rpm-config.
The actual complexity is not the issue here. I don't see a reason for not to add another macro file into this long-time existing, well-known package, instead of generating yet another package with yet another license, with yet another set of problems. I don't see issue with backporting (copying) the separate GPG-macro-file among fedora stable versions..
Good point with the versioning scheme. Maybe this is the right time to change it? Is this the reason why bugzillas I reported against redhat-rpm-config are mostly untouched by maintainers?
Good point, but somebody should probably discuss this with RPM team .. and make you (as a FPC member) comfortable with changes there... because that package moves forward very slowly :(
Also, what is the difference with "approving" or "owning" the changes? I think that FPC should approve changes in fedora-rpm-macros, too, right?
The point I tried to underline was that doing this within redhat-rpm-config is equivalent to do this within fedora-rpm-macros. Same level of responsibility and risk, just additional traffic during '--installroot' and in bodhi.
redhat-rpm-config
fedora-rpm-macros
I would definitely understand your work-flow if you made your package optional -> needed to be explicitly BuildRequire'd.
My day-to-day life doesn't change, even with fedora-rpm-macros. Just because this is my hobby too, I need to have a look at yet another package, and I doubt that is necessary.
We discussed this at this weeks meeting (http://meetbot.fedoraproject.org/fedora-meeting-1/2016-10-06/fpc.2016-10-06-16.00.txt):
CC: fedora@senderek.ie added
There isn't really anything to announce or write up here. I still haven't found the time to actually complete the work I was trying to do before things were derailed.
Metadata Update from @tibbs: - Issue assigned to tibbs
Login to comment on this ticket.