Remove gcc, gcc-c++ and make from minimal build root

[Kevin Fenzi]

On Fri, 16 Jan 2015 14:53:36 +0100
Zbigniew Jędrzejewski-Szmek <zbyszek at in.waw.pl> wrote:

> Agreed. In principle, any package could affect the build of any other
> package (e.g. bash version could realistically influence build
> results), but we ignore this. As you say, something like this would
> happen only if there was some (significant) bug. Those bugs are dealt
> with individually when detected.
> 
> The same is true for the compiler version influencing the behaviour
> of compiled programs. This might happen, but very rarely. Generally
> updating the compiler should only result in changes in behaviour only
> when the program was buggy to begin with and relied on undefined
> behaviour, bad memory access, or similar.

Just to clarify here: mass rebuilds are done in a side tag. They
inherit the normal rawhide buildroot, and do not update it. So,
everything in the mass rebuild is built with (mostly) the same
buildroot. Things aren't added as they are rebuilt. Only at the end
when the side tag is merged back in is the rawhide buildroot updated
with all the new mass rebuilt builds. 

So, if packageA is mass rebuilt and that new build breaks building
packageB, we won't know of it until after the mass rebuild, both are
tagged in and the packageB maintainer tries to rebuild packageB for
some other reason. ;) 

I suppose someone with a lot of time on their hands and a good grasp of
graph theory could come up with a way to rebuild everything in an order
that would ensure that everything newly rebuilt was used to build the
next list. It would be much like bootstrapping a new arch. Also, I
suspect it would take a great deal more time than 40 hours. ;) 

kevin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20150116/d5b58f7e/attachment.sig>