[aur-general] Separating PKGBUILDs for architectures - Was: AUR and unsuported architectures

[Hugo Osvaldo Barrera]

On 2012-06-01 17:28, 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.
>>
> 
> 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.

Yes, if this is ever allowed, this needs to be writen in big neon fonts.
 Much like "AUR in unsupported" is written everywhere.

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

I'm guessing that originally packages could be available or not for
amd64, and later on, the if-then-else come to be. I do agree that
there's little reason to keep this, though changing it is plenty of work.

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

This would bring a lots of conviniences.  Multiarch packages still have
one SINGLE PKGBUILD, and packages with different builds can have
multiple PKGBUILD files.

A nice idea would be to have PKGBUILD with common data/functions, and
PKGBUILD.arch (ie: PKGBUILD.x86) with arch specific stuff.

This would add a lot to maintainability, and still clean up lots of
issues.  In many cases, the specific files just have different source
and checksum.  Or different files to install in package().

This would, of course, require plenty of changes to makepkg AFAIK.

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


-- 
Hugo Osvaldo Barrera