[aur-general] AUR and unsuported architectures

[Xyne]

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.