On Tue, 2007-05-29 at 19:07 -0500, Tom "spot" Callaway wrote: > > As this would require more than a policy change, I'm very hesitant to do > that. Koji would need some code changes to make this possible, I'm > committing to doing that work, but I don't want to waste time watching > everything catch on fire while everyone screams for that code to be > finished and the buildsystem fixed. > > I know this is going to break a lot for secondary architectures. Things > like glibc and gcc are going to fail a few times on sparc before we get > it right. Consider this for multiple secondary architectures (alpha, > arm, ia64, s390, sparc), and you start to see why this needs not to hold > up the primary architectures. That's a different situation to the one I was thinking of. You're talking about what happens while you're in the process of bringing a new architecture online. I was talking about _normal_ operation, once it's already been bootstrapped and it's up and running. For bootstrapping, I would assume that you'd start by building everything for the new architecture externally, and thus you'd have glibc and gcc packages working and tested on the full package set _long_ before you tie it into the build system and it starts breaking builds. I don't mind too much how you handle the bootstrap though -- as long as _normal_ builds continue to require a bug for every missing arch build (whether it be through ExcludeArch: or failure). Maybe you could allow failures for a short period of time after a new arch is brought on-line. But any package which has _previously_ built on a given architecture should continue to build on that architecture. It might be OK to allow the bug to be filed _after_ the build failure, explaining the reason for the failure and why it's outside the capabilities of the package maintainer to fix it. Then the package could be pushed for the architectures for which it _did_ build. But I don't see any real advantage to that over the current system; it's just more complexity. -- dwmw2 -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
