Hello list, you might notice that rebuild stopped for a while. I run out of packages, which had "normal" dependencies. Now I have a list of cyclic dependencies, which are dependent back and forth. Because we'll be doing mass rebuild every year, I'd like to use bootstrap macro, which could help us little. You can see example in perl-HTTP-Lite. There were dependencies for test suite like Test::Pod.
The macro perl_bootstrap is actually set to 1. After rebuild will be done, it will be switched to 0. So, now are marked buildrequires or test suites switched off. I'd like to use it at least in packages, which caused major problems. Please note that it doesn't broke your specfiles in EPEL.
Example: BuildArch: noarch BuildRequires: perl(ExtUtils::MakeMaker) %if !%{defined perl_bootstrap} BuildRequires: perl(Test::CPAN::Meta) BuildRequires: perl(Test::MinimumVersion) BuildRequires: perl(Test::Pod) %endif Requires: perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo $version))
%{?perl_default_filter} ... %check # most real tests require network access - ignore "skipping test on this # platform" messages %if !%{defined perl_bootstrap} RELEASE_TESTING=1 make test %endif ...
If you like imagine how bad it is, see: http://ppisar.fedorapeople.org/perl_rebuild/5.14/notbuilt.svg ;-) It doesn't contain current data, but it shows the most problematic places.
Best regards, Marcela
On Mon, Jun 27, 2011 at 01:28:58PM -0400, Marcela Maslanova wrote:
The macro perl_bootstrap is actually set to 1. After rebuild will be done, it will be switched to 0.
Correction: After rebuild is done, it will become undefined.
Additional information:
You can worry where the macro comes from. Originally, we put it into perl-devel subpackage. But that was not enough as Koji recreates SRPM from git repository and the macro must present at time of creatating the SRPM. Thus we put it into dependency of perl package that is pulled into build root just by accident (it's required by git).
Yes, this is another short-comming of Fedora build environment. Better place would be dependency of redhat-rpm-config that is explicitly listed in build and srpm-build package group.
If you like imagine how bad it is, see: http://ppisar.fedorapeople.org/perl_rebuild/5.14/notbuilt.svg ;-) It doesn't contain current data, but it shows the most problematic places.
The picture is horrible as it constructs package names from Perl module names. I will provide better one soon.
-- Petr
On Tue, Jun 28, 2011 at 08:58:58AM +0200, Petr Pisar wrote:
On Mon, Jun 27, 2011 at 01:28:58PM -0400, Marcela Maslanova wrote:
If you like imagine how bad it is, see: http://ppisar.fedorapeople.org/perl_rebuild/5.14/notbuilt.svg ;-) It doesn't contain current data, but it shows the most problematic places.
The picture is horrible as it constructs package names from Perl module names. I will provide better one soon.
I've uploaded new picture where destinations are real source package base names.
Graph explanation: This picture represents relation `a source package BuildRequires another source package'. It considers direct build-time dependencies only and it cuts degenerated leaf substrees (i.e. recursively removed packages that do buildrequire nothing). Input is set of not yet rebuilt packages. So the picture is not perfect, it's just a raw depiction.
-- Petr
On 06/28/2011 12:57 PM, Petr Pisar wrote:
On Tue, Jun 28, 2011 at 08:58:58AM +0200, Petr Pisar wrote:
On Mon, Jun 27, 2011 at 01:28:58PM -0400, Marcela Maslanova wrote:
If you like imagine how bad it is, see: http://ppisar.fedorapeople.org/perl_rebuild/5.14/notbuilt.svg ;-) It doesn't contain current data, but it shows the most problematic places.
The picture is horrible as it constructs package names from Perl module names. I will provide better one soon.
I've uploaded new picture where destinations are real source package base names.
Graph explanation: This picture represents relation `a source package BuildRequires another source package'. It considers direct build-time dependencies only and it cuts degenerated leaf substrees (i.e. recursively removed packages that do buildrequire nothing). Input is set of not yet rebuilt packages. So the picture is not perfect, it's just a raw depiction.
Do you have the data behind this graph somewhere? I'm trying to figure out where the circular build dependency between Test::EOL and Pod::Coverage::TrustPod is that necessitated turning off Pod::Coverage::TrustPod as a buildreq for Test::EOL when bootstrapping, and I can't really see it from the picture.
Paul.
On Thu, Jun 30, 2011 at 01:12:13PM +0100, Paul Howarth wrote:
On 06/28/2011 12:57 PM, Petr Pisar wrote:
On Tue, Jun 28, 2011 at 08:58:58AM +0200, Petr Pisar wrote:
On Mon, Jun 27, 2011 at 01:28:58PM -0400, Marcela Maslanova wrote:
If you like imagine how bad it is, see: http://ppisar.fedorapeople.org/perl_rebuild/5.14/notbuilt.svg ;-) It doesn't contain current data, but it shows the most problematic places.
The picture is horrible as it constructs package names from Perl module names. I will provide better one soon.
I've uploaded new picture where destinations are real source package base names.
Graph explanation: This picture represents relation `a source package BuildRequires another source package'. It considers direct build-time dependencies only and it cuts degenerated leaf substrees (i.e. recursively removed packages that do buildrequire nothing). Input is set of not yet rebuilt packages. So the picture is not perfect, it's just a raw depiction.
Do you have the data behind this graph somewhere? I'm trying to figure out where the circular build dependency between Test::EOL and Pod::Coverage::TrustPod is that necessitated turning off Pod::Coverage::TrustPod as a buildreq for Test::EOL when bootstrapping, and I can't really see it from the picture.
In the same directory as the SVG file, there is file without extension listing not yet rebuild source package base names. If you are curious for the generator, I can publish it too (but I'm quite ashamed of it).
-- Petr
On 06/30/2011 01:35 PM, Petr Pisar wrote:
On Thu, Jun 30, 2011 at 01:12:13PM +0100, Paul Howarth wrote:
On 06/28/2011 12:57 PM, Petr Pisar wrote:
On Tue, Jun 28, 2011 at 08:58:58AM +0200, Petr Pisar wrote:
On Mon, Jun 27, 2011 at 01:28:58PM -0400, Marcela Maslanova wrote:
If you like imagine how bad it is, see: http://ppisar.fedorapeople.org/perl_rebuild/5.14/notbuilt.svg ;-) It doesn't contain current data, but it shows the most problematic places.
The picture is horrible as it constructs package names from Perl module names. I will provide better one soon.
I've uploaded new picture where destinations are real source package base names.
Graph explanation: This picture represents relation `a source package BuildRequires another source package'. It considers direct build-time dependencies only and it cuts degenerated leaf substrees (i.e. recursively removed packages that do buildrequire nothing). Input is set of not yet rebuilt packages. So the picture is not perfect, it's just a raw depiction.
Do you have the data behind this graph somewhere? I'm trying to figure out where the circular build dependency between Test::EOL and Pod::Coverage::TrustPod is that necessitated turning off Pod::Coverage::TrustPod as a buildreq for Test::EOL when bootstrapping, and I can't really see it from the picture.
In the same directory as the SVG file, there is file without extension listing not yet rebuild source package base names. If you are curious for the generator, I can publish it too (but I'm quite ashamed of it).
Hopefully the raw data will suit my need - when I can get it:
$ wget http://ppisar.fedorapeople.org/perl_rebuild/5.14/notbuilt --2011-06-30 13:43:28-- http://ppisar.fedorapeople.org/perl_rebuild/5.14/notbuilt Resolving ppisar.fedorapeople.org... 85.236.55.7 Connecting to ppisar.fedorapeople.org|85.236.55.7|:80... connected. HTTP request sent, awaiting response... 403 Forbidden 2011-06-30 13:43:28 ERROR 403: Forbidden.
Paul.
On Thu, Jun 30, 2011 at 01:44:15PM +0100, Paul Howarth wrote:
On 06/30/2011 01:35 PM, Petr Pisar wrote:
On Thu, Jun 30, 2011 at 01:12:13PM +0100, Paul Howarth wrote:
On 06/28/2011 12:57 PM, Petr Pisar wrote:
On Tue, Jun 28, 2011 at 08:58:58AM +0200, Petr Pisar wrote:
On Mon, Jun 27, 2011 at 01:28:58PM -0400, Marcela Maslanova wrote:
If you like imagine how bad it is, see: http://ppisar.fedorapeople.org/perl_rebuild/5.14/notbuilt.svg ;-) It doesn't contain current data, but it shows the most problematic places.
The picture is horrible as it constructs package names from Perl module names. I will provide better one soon.
I've uploaded new picture where destinations are real source package base names.
Graph explanation: This picture represents relation `a source package BuildRequires another source package'. It considers direct build-time dependencies only and it cuts degenerated leaf substrees (i.e. recursively removed packages that do buildrequire nothing). Input is set of not yet rebuilt packages. So the picture is not perfect, it's just a raw depiction.
Do you have the data behind this graph somewhere? I'm trying to figure out where the circular build dependency between Test::EOL and Pod::Coverage::TrustPod is that necessitated turning off Pod::Coverage::TrustPod as a buildreq for Test::EOL when bootstrapping, and I can't really see it from the picture.
In the same directory as the SVG file, there is file without extension listing not yet rebuild source package base names. If you are curious for the generator, I can publish it too (but I'm quite ashamed of it).
Hopefully the raw data will suit my need - when I can get it:
$ wget http://ppisar.fedorapeople.org/perl_rebuild/5.14/notbuilt --2011-06-30 13:43:28-- http://ppisar.fedorapeople.org/perl_rebuild/5.14/notbuilt Resolving ppisar.fedorapeople.org... 85.236.55.7 Connecting to ppisar.fedorapeople.org|85.236.55.7|:80... connected. HTTP request sent, awaiting response... 403 Forbidden 2011-06-30 13:43:28 ERROR 403: Forbidden.
Oops. Permissions fixed.
-- Petr
On 06/30/2011 02:05 PM, Petr Pisar wrote:
On Thu, Jun 30, 2011 at 01:44:15PM +0100, Paul Howarth wrote:
On 06/30/2011 01:35 PM, Petr Pisar wrote:
On Thu, Jun 30, 2011 at 01:12:13PM +0100, Paul Howarth wrote:
On 06/28/2011 12:57 PM, Petr Pisar wrote:
On Tue, Jun 28, 2011 at 08:58:58AM +0200, Petr Pisar wrote:
On Mon, Jun 27, 2011 at 01:28:58PM -0400, Marcela Maslanova wrote:
> If you like imagine how bad it is, see: > http://ppisar.fedorapeople.org/perl_rebuild/5.14/notbuilt.svg ;-) It > doesn't contain current data, but it shows the most problematic places. >
The picture is horrible as it constructs package names from Perl module names. I will provide better one soon.
I've uploaded new picture where destinations are real source package base names.
Graph explanation: This picture represents relation `a source package BuildRequires another source package'. It considers direct build-time dependencies only and it cuts degenerated leaf substrees (i.e. recursively removed packages that do buildrequire nothing). Input is set of not yet rebuilt packages. So the picture is not perfect, it's just a raw depiction.
Do you have the data behind this graph somewhere? I'm trying to figure out where the circular build dependency between Test::EOL and Pod::Coverage::TrustPod is that necessitated turning off Pod::Coverage::TrustPod as a buildreq for Test::EOL when bootstrapping, and I can't really see it from the picture.
In the same directory as the SVG file, there is file without extension listing not yet rebuild source package base names. If you are curious for the generator, I can publish it too (but I'm quite ashamed of it).
Hopefully the raw data will suit my need - when I can get it:
$ wget http://ppisar.fedorapeople.org/perl_rebuild/5.14/notbuilt --2011-06-30 13:43:28-- http://ppisar.fedorapeople.org/perl_rebuild/5.14/notbuilt Resolving ppisar.fedorapeople.org... 85.236.55.7 Connecting to ppisar.fedorapeople.org|85.236.55.7|:80... connected. HTTP request sent, awaiting response... 403 Forbidden 2011-06-30 13:43:28 ERROR 403: Forbidden.
Oops. Permissions fixed.
Hmm, that file is just the list of unbuilt packages; I was looking for something that included the relationships between the packages so I could figure out why Test::EOL couldn't use Pod::Coverage::TrustPod when bootstrapping.
Paul.
On Thu, Jun 30, 2011 at 02:29:28PM +0100, Paul Howarth wrote:
On 06/30/2011 02:05 PM, Petr Pisar wrote:
On Thu, Jun 30, 2011 at 01:44:15PM +0100, Paul Howarth wrote:
On 06/30/2011 01:35 PM, Petr Pisar wrote:
On Thu, Jun 30, 2011 at 01:12:13PM +0100, Paul Howarth wrote:
On 06/28/2011 12:57 PM, Petr Pisar wrote:
On Tue, Jun 28, 2011 at 08:58:58AM +0200, Petr Pisar wrote: > On Mon, Jun 27, 2011 at 01:28:58PM -0400, Marcela Maslanova wrote: > >> If you like imagine how bad it is, see: >> http://ppisar.fedorapeople.org/perl_rebuild/5.14/notbuilt.svg ;-) It >> doesn't contain current data, but it shows the most problematic places. >> > > The picture is horrible as it constructs package names from Perl module > names. I will provide better one soon. > I've uploaded new picture where destinations are real source package base names.
Graph explanation: This picture represents relation `a source package BuildRequires another source package'. It considers direct build-time dependencies only and it cuts degenerated leaf substrees (i.e. recursively removed packages that do buildrequire nothing). Input is set of not yet rebuilt packages. So the picture is not perfect, it's just a raw depiction.
Do you have the data behind this graph somewhere? I'm trying to figure out where the circular build dependency between Test::EOL and Pod::Coverage::TrustPod is that necessitated turning off Pod::Coverage::TrustPod as a buildreq for Test::EOL when bootstrapping, and I can't really see it from the picture.
In the same directory as the SVG file, there is file without extension listing not yet rebuild source package base names. If you are curious for the generator, I can publish it too (but I'm quite ashamed of it).
Hopefully the raw data will suit my need - when I can get it:
$ wget http://ppisar.fedorapeople.org/perl_rebuild/5.14/notbuilt --2011-06-30 13:43:28-- http://ppisar.fedorapeople.org/perl_rebuild/5.14/notbuilt Resolving ppisar.fedorapeople.org... 85.236.55.7 Connecting to ppisar.fedorapeople.org|85.236.55.7|:80... connected. HTTP request sent, awaiting response... 403 Forbidden 2011-06-30 13:43:28 ERROR 403: Forbidden.
Oops. Permissions fixed.
Hmm, that file is just the list of unbuilt packages; I was looking for something that included the relationships between the packages so I could figure out why Test::EOL couldn't use Pod::Coverage::TrustPod when bootstrapping.
Yeah, I know :) You can get the drawing script from http://ppisar.fedorapeople.org/perl_rebuild/depgraph. It gets BuildRequires for each listed source package, translate them to corresponding source package name and put them into directed graph.
(This is done calling repoquery which is really slow. Therefore I packaged perl-YUM-RepoQuery few days ago, but had not time to use it.)
(Also it considers direct BuildRequires only. I'm implementing indirect dependenices into mass rebuild script now, so it could be reused, maybe.)
Then it removes all leafs recursively and finally it uses graphviz do draw the graph.
I would like to minimaze the graph to cycles only. Cycle finding is not implemented yet but it should be trivial within O(V×E): just flood a name of a vertex, and if the wave hit the origin, the vertex is in cycle; and do it for each vertex.
-- Petr
On Thu, Jun 30, 2011 at 5:32 PM, Petr Pisar ppisar@redhat.com wrote:
You can get the drawing script from http://ppisar.fedorapeople.org/perl_rebuild/depgraph. It gets BuildRequires for each listed source package, translate them to corresponding source package name and put them into directed graph.
(This is done calling repoquery which is really slow. Therefore I packaged perl-YUM-RepoQuery few days ago, but had not time to use it.)
(Also it considers direct BuildRequires only. I'm implementing indirect dependenices into mass rebuild script now, so it could be reused, maybe.)
Then it removes all leafs recursively and finally it uses graphviz do draw the graph.
I would like to minimaze the graph to cycles only. Cycle finding is not implemented yet but it should be trivial within O(V×E): just flood a name of a vertex, and if the wave hit the origin, the vertex is in cycle; and do it for each vertex.
Interesting though this is, why are we trying to bootstrap the entire rebuild? Perl 5.14 is sufficiently compatible with 5.12 that we can continue to provide perl(:MODULE_COMPAT_5.12.*) in perl-5.14.1 rpm until the rebuild is (nearly) complete and only need to worry about bootstrapping the arch-specific stuff (a much smaller problem set with no circular deps that affected my rebuild in mock). Once all the arch-specific stuff is rebuilt, all of the noarch packages should just work (except those with real failures due to new features - mostly regex stringification messing up tests).
On Thu, Jun 30, 2011 at 06:08:49PM +0200, Iain Arnell wrote:
Interesting though this is, why are we trying to bootstrap the entire rebuild? Perl 5.14 is sufficiently compatible with 5.12 that we can continue to provide perl(:MODULE_COMPAT_5.12.*) in perl-5.14.1 rpm until the rebuild is (nearly) complete and only need to worry about bootstrapping the arch-specific stuff (a much smaller problem set with no circular deps that affected my rebuild in mock). Once all the arch-specific stuff is rebuilt, all of the noarch packages should just work (except those with real failures due to new features - mostly regex stringification messing up tests).
The noarch compatibility between 5.12 and 5.14 is almost perfect, but this could not be true in future upgrades. Being able to bootstrap perl fully automatically is great benefit. E.g we plan converting fractional versions to version object strings (due to compatibility with RPM), so bootstrap build is wanted prerequisite. (Not mentioning moving packages between distributions or testing other crazy ideas like parallel installation of different Perl versions). I remember 5.12 rebuild and it was horror because of mixing old and new builds. If new Perl is going to be released each year, we need to have automated solution that can deal with all (ok. almost all) potential problems the Perl rebase can bring.
-- Petr
On Fri, Jul 1, 2011 at 9:29 AM, Petr Pisar ppisar@redhat.com wrote:
On Thu, Jun 30, 2011 at 06:08:49PM +0200, Iain Arnell wrote:
Interesting though this is, why are we trying to bootstrap the entire rebuild? Perl 5.14 is sufficiently compatible with 5.12 that we can continue to provide perl(:MODULE_COMPAT_5.12.*) in perl-5.14.1 rpm until the rebuild is (nearly) complete and only need to worry about bootstrapping the arch-specific stuff (a much smaller problem set with no circular deps that affected my rebuild in mock). Once all the arch-specific stuff is rebuilt, all of the noarch packages should just work (except those with real failures due to new features - mostly regex stringification messing up tests).
The noarch compatibility between 5.12 and 5.14 is almost perfect, but this could not be true in future upgrades. Being able to bootstrap perl fully automatically is great benefit. E.g we plan converting fractional versions to version object strings (due to compatibility with RPM), so bootstrap build is wanted prerequisite. (Not mentioning moving packages between distributions or testing other crazy ideas like parallel installation of different Perl versions). I remember 5.12 rebuild and it was horror because of mixing old and new builds. If new Perl is going to be released each year, we need to have automated solution that can deal with all (ok. almost all) potential problems the Perl rebase can bring.
Sure, full bootstrap rebuild would be nice to have. But wouldn't it be better to work out the details locally using mock first?
We're now approaching the fourth week of this mass rebuild and still have at least 700 packages to go.... The branch/feature freeze is already less than one month away.
On 07/01/2011 03:47 PM, Iain Arnell wrote:
On Fri, Jul 1, 2011 at 9:29 AM, Petr Pisarppisar@redhat.com wrote:
On Thu, Jun 30, 2011 at 06:08:49PM +0200, Iain Arnell wrote:
Interesting though this is, why are we trying to bootstrap the entire rebuild? Perl 5.14 is sufficiently compatible with 5.12 that we can continue to provide perl(:MODULE_COMPAT_5.12.*) in perl-5.14.1 rpm until the rebuild is (nearly) complete and only need to worry about bootstrapping the arch-specific stuff (a much smaller problem set with no circular deps that affected my rebuild in mock). Once all the arch-specific stuff is rebuilt, all of the noarch packages should just work (except those with real failures due to new features - mostly regex stringification messing up tests).
The noarch compatibility between 5.12 and 5.14 is almost perfect, but this could not be true in future upgrades. Being able to bootstrap perl fully automatically is great benefit. E.g we plan converting fractional versions to version object strings (due to compatibility with RPM), so bootstrap build is wanted prerequisite. (Not mentioning moving packages between distributions or testing other crazy ideas like parallel installation of different Perl versions). I remember 5.12 rebuild and it was horror because of mixing old and new builds. If new Perl is going to be released each year, we need to have automated solution that can deal with all (ok. almost all) potential problems the Perl rebase can bring.
Sure, full bootstrap rebuild would be nice to have. But wouldn't it be better to work out the details locally using mock first?
We're now approaching the fourth week of this mass rebuild and still have at least 700 packages to go.... The branch/feature freeze is already less than one month away.
Yes, we are aware of it. Hopefully it shouldn't take so much time now.
We can always build it last week before alpha in old stupid way.
On Thu, Jun 30, 2011 at 3:29 PM, Paul Howarth paul@city-fan.org wrote:
Hmm, that file is just the list of unbuilt packages; I was looking for something that included the relationships between the packages so I could figure out why Test::EOL couldn't use Pod::Coverage::TrustPod when bootstrapping.
It seems to be due to perl-Test-Pod (a build requirement of Pod::Coverage::TrustPod), which is using Module::Build at build-time. And dual-life Module::Build has a whole bunch of additional build dependencies, presumably at least one of which is also using Test-Pod. And looking at Marcela's commits, it seems that most of the bootstrap problems so far seem to involve removing Test-Pod{,-Coverage} deps. I would suggest that a better solution is to change perl-Test-Pod's packaging to use EU::MM and Makefile.PL instead of Module::Build (Test-Pod offers both).
On 07/02/2011 12:57 PM, Iain Arnell wrote:
On Thu, Jun 30, 2011 at 3:29 PM, Paul Howarthpaul@city-fan.org wrote:
Hmm, that file is just the list of unbuilt packages; I was looking for something that included the relationships between the packages so I could figure out why Test::EOL couldn't use Pod::Coverage::TrustPod when bootstrapping.
It seems to be due to perl-Test-Pod (a build requirement of Pod::Coverage::TrustPod), which is using Module::Build at build-time. And dual-life Module::Build has a whole bunch of additional build dependencies, presumably at least one of which is also using Test-Pod. And looking at Marcela's commits, it seems that most of the bootstrap problems so far seem to involve removing Test-Pod{,-Coverage} deps. I would suggest that a better solution is to change perl-Test-Pod's packaging to use EU::MM and Makefile.PL instead of Module::Build (Test-Pod offers both).
Even that isn't really necessary as the Module::Build built as part of the main perl package could be used to bootstrap perl-Test-Pod.
Paul.
On Mon, Jun 27, 2011 at 7:28 PM, Marcela Maslanova mmaslano@redhat.com wrote:
Hello list, you might notice that rebuild stopped for a while. I run out of packages, which had "normal" dependencies. Now I have a list of cyclic dependencies, which are dependent back and forth. Because we'll be doing mass rebuild every year, I'd like to use bootstrap macro, which could help us little. You can see example in perl-HTTP-Lite. There were dependencies for test suite like Test::Pod.
The macro perl_bootstrap is actually set to 1. After rebuild will be done, it will be switched to 0. So, now are marked buildrequires or test suites switched off. I'd like to use it at least in packages, which caused major problems. Please note that it doesn't broke your specfiles in EPEL.
Example: BuildArch: noarch BuildRequires: perl(ExtUtils::MakeMaker) %if !%{defined perl_bootstrap} BuildRequires: perl(Test::CPAN::Meta) BuildRequires: perl(Test::MinimumVersion) BuildRequires: perl(Test::Pod) %endif Requires: perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo $version))
%{?perl_default_filter} ... %check # most real tests require network access - ignore "skipping test on this # platform" messages %if !%{defined perl_bootstrap} RELEASE_TESTING=1 make test %endif ...
Marcela,
I think that when using perl_bootstrap macro in this way, it would also be useful to make the necessary info available in repository metadata so that we can easily find these bootstrappable packages in future (to rebuild without bootstrap) and to know which of their dependencies are soft. Maybe in your example we could also
Provides: perl-bootstrap(Test::CPAN::Meta) Provides: perl-bootstrap(Test::MinimumVersion) Provides: perl-bootstrap(Test::Pod)
On 07/14/2011 07:42 AM, Iain Arnell wrote:
On Mon, Jun 27, 2011 at 7:28 PM, Marcela Maslanovammaslano@redhat.com wrote:
Hello list, you might notice that rebuild stopped for a while. I run out of packages, which had "normal" dependencies. Now I have a list of cyclic dependencies, which are dependent back and forth. Because we'll be doing mass rebuild every year, I'd like to use bootstrap macro, which could help us little. You can see example in perl-HTTP-Lite. There were dependencies for test suite like Test::Pod.
The macro perl_bootstrap is actually set to 1. After rebuild will be done, it will be switched to 0. So, now are marked buildrequires or test suites switched off. I'd like to use it at least in packages, which caused major problems. Please note that it doesn't broke your specfiles in EPEL.
Example: BuildArch: noarch BuildRequires: perl(ExtUtils::MakeMaker) %if !%{defined perl_bootstrap} BuildRequires: perl(Test::CPAN::Meta) BuildRequires: perl(Test::MinimumVersion) BuildRequires: perl(Test::Pod) %endif Requires: perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo $version))
%{?perl_default_filter} ... %check # most real tests require network access - ignore "skipping test on this # platform" messages %if !%{defined perl_bootstrap} RELEASE_TESTING=1 make test %endif
I'd like to see comments added regarding the use of perl-bootstrap to show where the circular dependency is; these cycles may change over time as module implementations change, and some upstream module writers explicitly drop dependencies to avoid cycles, so it's useful to know why a BR was guarded by perl_bootstrap as it may be possible to remove it at a later date.
I've just added this in perl-Net-SSLeay for instance:
# Test::Kwalitee => Module::CPANTS::Analyze => Net::HTTP => IO::Socket::SSL => Net::SSLeay %if 0%{!?perl_bootstrap:1} BuildRequires: perl(Test::Kwalitee) %endif
Paul.
perl-devel@lists.fedoraproject.org