On 2011-10-05, Tom Lane <tgl@xxxxxxxxxx> 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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel