>> In an extreme situation, a release could be nearly impossible due to >> dependency cycles. > >You'd need to provide specific examples for "extreme" as this has not >happened in recent Fedora history (at least back to F-21) I cannot cite an historical example. With more than a thousand packages in the Live edition, and several thousand in the Workstation edition, it seems severe to insist they must all (except hardware-specific) work in the primary architectures or a release is automatically blocked. That may be the right thing to do, and handle any situations that are too awkward on an exception basis. To concoct an extreme situation, suppose the Firefox developers decide that a newer version of GCC is necessary to build for the ARM architecture. I would argue the appropriate choice is to release Fedora without Firefox in the ARM builds, and include Firefox for ARM in a later release. I do not consider this a reason to remove a valuable Firefox from X86 builds. In a general sense, one might argue any time a program works on one architecture but fails on another, this must involve hardware enablement at some level. A compiler enables convenient use of a machine's architecture-specific instruction set and hardware features, therefore any application that uses this compiler is hardware-specific, and enables that hardware in some way. None of this reduces the value of a consistent Fedora experience across architectures. I believe this objective should influence choices about what to include in the default package set, and where to allocate development resources, but not forbid packages that deliver significant value. Most users are likely to quickly augment Fedora with their favorite applications and configuration, and thereby make their Fedora different from the default experience. It is still valuable to strive for consistency across architectures, but wrong to pretermit valuable applications only because they do not, or cannot, support some architecture. _______________________________________________ test mailing list -- test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to test-leave@xxxxxxxxxxxxxxxxxxxxxxx
