Dealing with circular BuildRequires?

Petr Pisar ppisar at
Wed Oct 5 08:24:01 UTC 2011

On 2011-10-05, Tom Lane <tgl at> wrote:
> So I started experimenting with updating libpng to a new release series,
> and soon found out that it was impossible to rebuild its dependencies.
> For example, cairo BuildRequires: librsvg2-devel, and librsvg2
> BuildRequires: cairo-devel, so there is no order in which I can rebuild
> them.  How the heck did we get into such a situation, and what should
> I do about it?  Neither specfile appears to have any provision for
> bootstrapping.
We had similar problem when upgrading Perl to 5.14.

First, we choosed dependecy-ordered builds which stopped after
rebuilding about one thousand packages. Then we hit circular
dependencies blocking remaining eight hunderds packages.

Thus we introduced perl-specific bootstrap macro delivered by `perl'
package and we conditionalized some parts of spec files by the macro.
Unfortunatelly because of lack of time we stopped this process by
falling back lying the new perl package provides old Perl capabilities.
Naturally, we rebuilt the bootstrapped packages after removing the
bootstrap macro from `perl' package again.

But the big problem was *where to define the bootstrap macro because
SRPMs are rebuilt in Koji within minimal build root and we need the
macro available at this early stage*. Fortunatelly `perl' is part of
build root, so we put it there. Originally we wanted to put the macro
into perl-devel package, but this one is not available in the SRPM build
root. I thing this is the real problem.

There should be some package in build root driving bootstrapping and the
package should be writeable by a lot of packagers. I don't think
redhat-rpm-config is the best one. I think redhat-rpm-config should
require other packages provided by owneres of bootstrapp-causing packages like
perl, libpng etc.

-- Petr

More information about the devel mailing list