I'm fine with option 1, but I'm curious why the rpmbuild dependency was changed and if it was discussed anywhere. Seems like something that is going to impact end-users, not just the koji buildroots.

The rpmbuild dependency has been part of the system-python plan since the beginning, IIRC. It was implicitly approved as part of https://fedoraproject.org/wiki/Changes/System_Python but then it didn't happen in time for F24 or F25.

The Base Runtime efforts eliminated python-requiring packages down to only rpmbuild; by switching that to system-python, we no longer need to have the full python stack in the Base.

The rpmbuild dependency has been part of the system-python plan since the beginning, IIRC. It was implicitly approved as part of https://fedoraproject.org/wiki/Changes/System_Python but then it didn't happen in time for F24 or F25.

The lack of follow through on announcing the change is concerning. Particularly since people will have long forgotten about it until something like this happens.

The Base Runtime efforts eliminated python-requiring packages down to only rpmbuild; by switching that to system-python, we no longer need to have the full python stack in the Base.

That's excellent and I don't wish to revert the change. I simply want it announced in advance.

That's excellent and I don't wish to revert the change. I simply want it announced in advance.

I completely agree. I wasn't happy when I heard about the impact either, but I think it was basically just a case of unintended consequences. They didn't realize that python had been in the buildroot implicitly via rpmbuild. It was assumed that it was present explicitly.

Anyway, since I don't have a time machine, I can't force them to announce it in advance. If we want to go that route, then option 2 or 3 above, followed by a devel-announce post stating a flag day when that will change would be the closest thing.

That said, I'm not convinced that the impact will be too high, since the majority of Python projects BR other python modules which in turn would pull in the main python stack.

considering people are supposed to BuildRequire everything that thier package depends on. the only thing you can ignore are the limited packages explicitly listed, The only thing we should do is give people a heads up that they may need to fix things if they have not followed the packaging guidelines fully. I do not think it needed to be announced honestly.

considering people are supposed to BuildRequire everything that thier package depends on. the only thing you can ignore are the limited packages explicitly listed, The only thing we should do is give people a heads up that they may need to fix things if they have not followed the packaging guidelines fully. I do not think it needed to be announced honestly.

While I agree with you, I still think announcing it prior the change would have been better. Communication never hurts. And by the way, it wasn't just the rpm-build (pulling python in), it was also gettext (and python3).

I started working on a change proposal, as we had a similar thing for the (albeit more complex) removal of perl. I also filed, unaware of this discussion, an infra ticket for adding python and python3 to the build and srpm-build groups in rawhide (option 3 here). I consider that to be the easiest solution in this case -- https://pagure.io/fedora-infrastructure/issue/5654

Anyway, since the impact will be probably very small and won't require any mass packaging changes like the perl removal did, I wonder -- do we even need the change proposal for this?

I am opposed to expanding the minimal buildroot for this. Extra communication will only help, however everything was well within the guildelines. I suggest we make sure it is announced now and move forward.

+1 to just announcing this and moving on. I don't think we need a process here as maintainers should have been requiring python already.

+1 to announcing and moving on, as well.

+1 from me as well

+1 from me for option 1

We have 5 +1s in this ticket. Please announce the change on devel list and move on.