On Wed, 2007-07-11 at 22:02 -0500, Tom "spot" Callaway wrote: > Most open source apps build fine on SPARC. Those that do not are > either: > > - endian unclean > - missing sparc configure options > - miscompile on sparc64 > - glibc/gcc/kernel/openssl (only broken on sparc) > - tools need to be made aware of sparc specifics > - irrelevant on sparc I've seen some of that kind of thing too -- but those are generally things which prevent the package from ever getting built in the first place, and thus largely outside the scope of what we were talking about. Of _course_ the arch team is expected to get involved in the _first_ build of the package set. And there should be an ExcludeArch (and corresponding bug) in place for any package which isn't yet ported, before the secondary arch ever comes online. The case we were discussing wasn't the _first_ build of a package though -- it was the case when a package fails, but it _used_ to build OK. _Those_ failures do tend to be generic bugs at least half the time, in my experience. And thus the failures are worthy of at least a _glance_ from the maintainer before shipping the failed package. I'm not saying the maintainer should be on the hook to _fix_ it every time, like we used to be for s390 (although I appreciate that some people have been psychologically scarred for life by that experience and thus find it difficult to rationally contemplate what I'm saying). I'm just saying that the maintainer should be expected to _look_ at the log and make a conscious decision about the failure mode and the pros and cons of shipping the partially-failed package anyway. That really isn't much of a burden. -- dwmw2 -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
