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.
