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