On Wednesday, September 02, 2015 10:58:54 AM Colin Walters wrote:

Because Fedora is a self-hosted system, circular dependencies are a fact of life. Self-hosted compilers and the like will always exist.

But I think the circular BR nature of redhat-rpm-config and macro packages is unnecessary self-inflicted pain. Currently, I am trying to backport (into a downstream distribution) the introduction of go-srpm-macros into redhat-rpm-config:

http://pkgs.fedoraproject.org/cgit/redhat-rpm-config.git/commit/?id=ba49b893 751cd036905b642bc671814301cd2edb

Yet because redhat-rpm-config itself is pulled into the build root for go-srpm-macros, it introduces a circular build dependency.

I could imagine external ways out of this (try dropping the BR of rrc for go-srpm-macros externally), but it would seem to me to be a lot saner just to include the macros themselves in redhat-rpm-config.

Thoughts? (Is this the right list?)

The right list would be devel@. Long ago we used to have the ghc etc srpm macros in redhat-rpm-config, they were changing quite often, as arches were added or removed and it was decided to split them out. I do not have a strong opinion either way. we just need to ensure that they are available at srpm creation time, and adding a bunch of packages to the group that we try to keep minimal seems wrong.

Most languages have macros for building binary rpms in different rpms that they BuildRequire, the srpm macros are purely for things that need to be defined in the buildroot when we build the srpm. Since we can not add them as a BuildRequires we have to make sure they are there.

What we probably should do is add a bootstrap macro and enable all the different srpm Requires to be dropped for bootstrapping purposes.

Dennis