Loui Chang wrote:
It may be a bit of chicken-and-egg, though. The ppc/arm userbase might grow if arch is seen stable enough and seems to have sufficient packages, possibly making it worth being supported, but the lack of infrastructure won't make that so possible.
Yes, I also see it as a way of welcoming the ppc/arm/etc userbase into the main Arch collective, and adding their technological distinctiveness to our own.
I think that other architectures should be allowed to peacefully coexist in the AUR. Some of them may gain enough momentum to get official support (which will also require either new devs coming in or existing devs getting currently unsupported hardware). Until that happens, it should be made clear on the site that other architectures are not officially supported and that users cannot expect help with them. They can still seek help in the "Other Architectures" area of the forum, the existence of which is itself somewhat supportive of allowing other architectures. If we did that then we would have to emphasize that architecture-specific packages are only allowed when the included modification is necessary for full functionality. The rest of this message is mostly a train of thought that I cut out from the preceding part. At first I thought to propose a naming scheme for architecture-specific packages similar to VCS or programming language module packages, but that would be messy. The real problem is that each architecture has a different "namespace" for packages. It just so happens that i686 and x86_64 packages often require no changes, so we can use the same PGKBUILD for both. I doubt that there is any impetus for it, but the ideal solution would be to separate the namespaces in ABS and AUR. Most PKGBUILDs would remain the same. Packages for multiple architectures would be copied into each namespace (e.g. arch=(i686 x86_64) would be copied to i686 and x86_64). This is what happens with built packages already, but the PKGBUILDs are still jumbled together in ABS and AUR for <convenience|laziness|tradition|tacos>. The real change would be that instead of having PKGBUILDs with complicated if-then-else blocks to handle architecture, we would have PKGBUILDs for each architecture *in those cases*, i.e. when changes are required for a particular architecture. Or maybe we could just use the current split PKGBUILD framework for doing something similar, with architecture-specific packages named foo-<arch> in the PKGBUILD. Meh, I'm mostly thinking out loud here. The point was simply that there would be a way to have a namespace for unsupported architectures living side-by-side with the supported ones. Ultimately I still think that it's unfortunate that all of the metadata is locked up in Bash. It difficilitates the creation of many practical metapackaging tools. If anyone wants to play around with this idea, reply in a new thread. I've left this in the old one because I don't expect any real discussion, but it might be interesting.