[aur-general] Separating PKGBUILDs for architectures

[Loui Chang]

On Fri 01 Jun 2012 20:28 +0000, Xyne wrote:
> 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.
>
> 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>.

Yeah this is not a bad idea. It would reduce need for complexity in
PKGBUILDs

> 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.

The problem is with the PKGBUILD design. It wasn't really designed for
multi-architectures, or even for fully supporting source builds. I don't
really like the idea of building hacks upon hacks upon a format
ill-suited for current needs.

> 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.

Yep. In terms of metadata I guess a good first step would be to use some
simple clean format that is meant for data, not execution. Maybe
pkginfo, (pacman db), yaml or something.