On Fri, 16 Jan 2015 14:53:36 +0100 Zbigniew Jędrzejewski-Szmek <zbyszek@xxxxxxxxx> 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
Attachment:
pgpumxHAlUNlv.pgp
Description: OpenPGP digital signature
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
