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.