[aur-general] AUR and unsuported architectures
Hi,
I've recently seen some comments in AUR, where a user points out that X package works well on powerpc/arm.
I was wondering what's the general approach given to these architectures on AUR; since AUR is unsupported, is it ok to add these architectures to the PKGBUILD's arch array?
If it is ok, is it *advised* to do so when apropriate? Supported architectures should see absolutely no change regarding these packages, and unsupported one will benefit from it.
Again, being AUR unsupported anyway, I see nothing bad out of this, but I'd like to know the TU's stance on this, especially since I'm about to install archlinuxppc on one of my laptops. :)
Cheers, thanks,
On 31/05/12 01:58, Hugo Osvaldo Barrera wrote:
Hi,
I've recently seen some comments in AUR, where a user points out that X package works well on powerpc/arm.
I was wondering what's the general approach given to these architectures on AUR; since AUR is unsupported, is it ok to add these architectures to the PKGBUILD's arch array?
If it is ok, is it *advised* to do so when apropriate? Supported architectures should see absolutely no change regarding these packages, and unsupported one will benefit from it.
Again, being AUR unsupported anyway, I see nothing bad out of this, but I'd like to know the TU's stance on this, especially since I'm about to install archlinuxppc on one of my laptops. :)
Cheers, thanks,
When I first though about it, I wanted to say "why not", it doesn't hurt the functioning of the normal i686,x86_64 packages.
Except there might be a few drawbacks: * Become a place where ARM/PPC/* will look for support * ARM/PPC/* Folks might want to add patches specific for their architecture to AUR packages.
And could it potentially lead to AUR packages uploaded without either 'i686' or 'x86_64' set?
On Thu, May 31, 2012 at 09:38:05AM +0200, Jelle van der Waa wrote:
On 31/05/12 01:58, Hugo Osvaldo Barrera wrote:
Hi,
I've recently seen some comments in AUR, where a user points out that X package works well on powerpc/arm.
I was wondering what's the general approach given to these architectures on AUR; since AUR is unsupported, is it ok to add these architectures to the PKGBUILD's arch array?
If it is ok, is it *advised* to do so when apropriate? Supported architectures should see absolutely no change regarding these packages, and unsupported one will benefit from it.
Again, being AUR unsupported anyway, I see nothing bad out of this, but I'd like to know the TU's stance on this, especially since I'm about to install archlinuxppc on one of my laptops. :)
Cheers, thanks,
When I first though about it, I wanted to say "why not", it doesn't hurt the functioning of the normal i686,x86_64 packages.
Except there might be a few drawbacks:
- Become a place where ARM/PPC/* will look for support
- ARM/PPC/* Folks might want to add patches specific for their
architecture to AUR packages.
-- Jelle van der Waa
On 31 May 2012 17:38, Jelle van der Waa jelle@vdwaa.nl wrote:
When I first though about it, I wanted to say "why not", it doesn't hurt the functioning of the normal i686,x86_64 packages.
I thought the same, but after thinking more... While AUR is "unsupported", the project/site is still an official item.
In my mind, it doesn't make sense to include unofficial platforms in official infrastructure, supported or not.
We don't encourage documentation of other platforms in our wiki (do we?)
On Thu, May 31, 2012 at 1:10 PM, Phillip Smith lists@fukawi2.nl wrote:
I thought the same, but after thinking more... While AUR is "unsupported", the project/site is still an official item.
In my mind, it doesn't make sense to include unofficial platforms in official infrastructure, supported or not.
I agree.
On 2012-05-31 08:10, Phillip Smith wrote:
On 31 May 2012 17:38, Jelle van der Waa jelle@vdwaa.nl wrote:
When I first though about it, I wanted to say "why not", it doesn't hurt the functioning of the normal i686,x86_64 packages.
I thought the same, but after thinking more... While AUR is "unsupported", the project/site is still an official item.
In my mind, it doesn't make sense to include unofficial platforms in official infrastructure, supported or not.
We don't encourage documentation of other platforms in our wiki (do we?)
While I'd wish this weren't true, your argument does make perfect sense, so I guess it's best to keep AUR clear of these architectures.
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.
In any case, it's good to know the official stance so I know what to do in these sort of cases.
Thanks,
On Thu 31 May 2012 09:56 -0300, Hugo Osvaldo Barrera wrote:
On 2012-05-31 08:10, Phillip Smith wrote:
On 31 May 2012 17:38, Jelle van der Waa jelle@vdwaa.nl wrote:
When I first though about it, I wanted to say "why not", it doesn't hurt the functioning of the normal i686,x86_64 packages.
I thought the same, but after thinking more... While AUR is "unsupported", the project/site is still an official item.
In my mind, it doesn't make sense to include unofficial platforms in official infrastructure, supported or not.
We don't encourage documentation of other platforms in our wiki (do we?)
While I'd wish this weren't true, your argument does make perfect sense, so I guess it's best to keep AUR clear of these architectures.
I'm not a TU, but I actually think allowing other architectures in the PKGBUILDs is a Good Thing. The AUR is supposed be be a place of less-restricted user contribution - where packages (and/or architectures?) that developers are not interested in can be submitted.
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.
On 01/06/12 02:31, Loui Chang wrote:
On Thu 31 May 2012 09:56 -0300, Hugo Osvaldo Barrera wrote:
On 2012-05-31 08:10, Phillip Smith wrote:
On 31 May 2012 17:38, Jelle van der Waa jelle@vdwaa.nl wrote:
When I first though about it, I wanted to say "why not", it doesn't hurt the functioning of the normal i686,x86_64 packages.
I thought the same, but after thinking more... While AUR is "unsupported", the project/site is still an official item.
In my mind, it doesn't make sense to include unofficial platforms in official infrastructure, supported or not.
We don't encourage documentation of other platforms in our wiki (do we?)
While I'd wish this weren't true, your argument does make perfect sense, so I guess it's best to keep AUR clear of these architectures.
I'm not a TU, but I actually think allowing other architectures in the PKGBUILDs is a Good Thing. The AUR is supposed be be a place of less-restricted user contribution - where packages (and/or architectures?) that developers are not interested in can be submitted.
Sure it's not a problem or against the rules. I'm just afraid that ARM users will use the AUR and then complain that stuff doesn't work.
As I have seen with for example archbang and archlinuxarm questions on #archlinux.
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.
On 2012-06-01 03:17, Jelle van der Waa wrote:
On 01/06/12 02:31, Loui Chang wrote:
On Thu 31 May 2012 09:56 -0300, Hugo Osvaldo Barrera wrote:
On 2012-05-31 08:10, Phillip Smith wrote:
On 31 May 2012 17:38, Jelle van der Waa jelle@vdwaa.nl wrote:
When I first though about it, I wanted to say "why not", it doesn't hurt the functioning of the normal i686,x86_64 packages.
I thought the same, but after thinking more... While AUR is "unsupported", the project/site is still an official item.
I agree, this is quite true, and I actually must agree that ppc/arm would be out-of-place because of this.
In my mind, it doesn't make sense to include unofficial platforms in official infrastructure, supported or not.
We don't encourage documentation of other platforms in our wiki (do we?)
I don't know if it's allowed, but I should point that this article exists in the wiki: https://wiki.archlinux.org/index.php/Official_Install_Guide_on_a_PowerPC
I don't think it should say "official". Or it should at least mention it's unsupported by arch, BTW.
While I'd wish this weren't true, your argument does make perfect sense, so I guess it's best to keep AUR clear of these architectures.
I'm not a TU, but I actually think allowing other architectures in the PKGBUILDs is a Good Thing. The AUR is supposed be be a place of less-restricted user contribution - where packages (and/or architectures?) that developers are not interested in can be submitted.
Sure it's not a problem or against the rules. I'm just afraid that ARM users will use the AUR and then complain that stuff doesn't work.
I've seen people complaining that pacman can't install stuff from AUR too. We can't let out-of-place users become an impediment to move forward.
As I have seen with for example archbang and archlinuxarm questions on #archlinux.
I've seen Ubuntu and Fedora users asking stuff in #debian. Stupid people will always be stupid, you can't stop that!
The other reasons mentioned are valid (and I had actually backed down because of them), but I don't think this one should really have as much weight.
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.
Given that this question ("is arm/ppc allowed in AUR?") has had a bit of mixed responses, can I expect a bit more of discussion on this, or should I consider the "no" final?
Thanks,
On 01/06/12 08:17 PM, Hugo Osvaldo Barrera wrote:
Given that this question ("is arm/ppc allowed in AUR?") has had a bit of mixed responses, can I expect a bit more of discussion on this, or should I consider the "no" final? Thanks,
I wouldn't consider the "no" final. If you put a PKGBUILD in the AUR that says arch=('i686', 'x86_64' 'arm' 'ppc') and someone requests that it be deleted for that reason, I'm not going to delete it.
On 2 June 2012 11:21, Connor Behan connor.behan@gmail.com wrote:
On 01/06/12 08:17 PM, Hugo Osvaldo Barrera wrote:
Given that this question ("is arm/ppc allowed in AUR?") has had a bit of mixed responses, can I expect a bit more of discussion on this, or should I consider the "no" final? Thanks,
I wouldn't consider the "no" final. If you put a PKGBUILD in the AUR that says arch=('i686', 'x86_64' 'arm' 'ppc') and someone requests that it be deleted for that reason, I'm not going to delete it.
Look at it this way: why the hell should it matter to me if I'm not an 'arm' or 'ppc' user? The build would go just fine, and if I never look at the PKGBUILD, then nothing is different to me. So in the end, there's nothing wrong with that if the same PKGBUILD can be used across platforms.
-- GPG/PGP ID: C0711BF1
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.
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.
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.
On Thu, May 31, 2012 at 09:56:40AM -0300, Hugo Osvaldo Barrera wrote:
On 2012-05-31 08:10, Phillip Smith wrote:
On 31 May 2012 17:38, Jelle van der Waa jelle@vdwaa.nl wrote:
When I first though about it, I wanted to say "why not", it doesn't hurt the functioning of the normal i686,x86_64 packages.
I thought the same, but after thinking more... While AUR is "unsupported", the project/site is still an official item.
In my mind, it doesn't make sense to include unofficial platforms in official infrastructure, supported or not.
We don't encourage documentation of other platforms in our wiki (do we?)
While I'd wish this weren't true, your argument does make perfect sense, so I guess it's best to keep AUR clear of these architectures.
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.
Another possibility is that somebody in the ARM/PPC community steps up and reuse the AUR code (afair, it's GPL) to host a specific user repository for ARM/PPC/whatever.
That would clearly separate it from the current AUR.
However, it requires that somebody spends time to set it up and maintain it afterwards.
This probably also means that some PKGBUILDs would be available on both user repositories. I'm not sure it's such a good idea, since this would lead to more separation between the communities (e.g. PKGBUILD updates being applied differently on both repos, preventing a -- hypothetical as of now -- future merge to be conducted seamlessly).
On the other hands, for the moment being, many AUR maintainers do not have the hardware / time / will to support other architectures.
In any case, it's good to know the official stance so I know what to do in these sort of cases.
Thanks,
On Wed, May 30, 2012 at 08:58:57PM -0300, Hugo Osvaldo Barrera wrote:
I was wondering what's the general approach given to these architectures on AUR; since AUR is unsupported, is it ok to add these architectures to the PKGBUILD's arch array?
What about a modded aur client, I could write a patch to about any given aur helper within minutes that would add the arch to the PKGBUILD after download, which would simply add/enforce the desired arch.
I mean, it seems a silly answer to a question that raises somewhat complex concerns, but since arch guys like to homebrew things anyway, this seems to be what I'd "just do".
cheers! mar77i
On Mon, Jun 04, 2012 at 01:38:01AM +0200, Martti Kühne wrote:
What about a modded aur client, I could write a patch to about any given aur helper within minutes that would add the arch to the PKGBUILD after download, which would simply add/enforce the desired arch.
Excuse my inability to ignore the mess in that sentence.
What about a modded aur client, I could write a patch to about any given aur helper within minutes that would modify the PKGUBILD after download, and add/enforce the desired arch, giving it a shot in the dark.
...Also, one would find out soon enough if modifications are needed.
cheers! mar77i
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-06-03 20:44, Martti Kühne wrote:
On Mon, Jun 04, 2012 at 01:38:01AM +0200, Martti Kühne wrote:
What about a modded aur client, I could write a patch to about any given aur helper within minutes that would add the arch to the PKGBUILD after download, which would simply add/enforce the desired arch.
Excuse my inability to ignore the mess in that sentence.
What about a modded aur client, I could write a patch to about any given aur helper within minutes that would modify the PKGUBILD after download, and add/enforce the desired arch, giving it a shot in the dark.
...Also, one would find out soon enough if modifications are needed.
cheers! mar77i
But that would simply add "arm" or "ppc" to the ARCH array. The point is to know beforehand if the package works - currently I can know if a package works or not in my arch (amd64) by looking at the PKGBUILD. That's the whole point of that array.
- -- Hugo Osvaldo Barrera
On Sun, Jun 03, 2012 at 08:52:39PM -0300, Hugo Osvaldo Barrera wrote:
But that would simply add "arm" or "ppc" to the ARCH array. The point is to know beforehand if the package works - currently I can know if a package works or not in my arch (amd64) by looking at the PKGBUILD. That's the whole point of that array.
Ultimately it sounds like a good idea to set up a modified AUR for each of initially mirrors and modifies the arch of the current, later incoming packages to aur and then let them be adopted by the people who use the arches. Then, after the situation has fully surfaced, the "beforehand"-clause would be satisfied. Only few modificaitons are actually needed, like a field "untested" or something to indicate a package hasn't been acted upon or verified since the automatic conversion. If a user finds a verified, he might be able to unverify a package or be requested to use the comments section.
In a generalized approach this could solve even more of the current issues mentioned with aur, if it would incrementalize by version, per-arch-diffs and per-taco-diffs... making pkgbuilds patchwork. :)
cheers! mar77i
On Mon, Jun 4, 2012 at 2:12 AM, Martti Kühne mysatyre@gmail.com wrote:
On Sun, Jun 03, 2012 at 08:52:39PM -0300, Hugo Osvaldo Barrera wrote:
But that would simply add "arm" or "ppc" to the ARCH array. The point is to know beforehand if the package works - currently I can know if a package works or not in my arch (amd64) by looking at the PKGBUILD. That's the whole point of that array.
Ultimately it sounds like a good idea to set up a modified AUR for each of initially mirrors and modifies the arch of the current, later incoming packages to aur and then let them be adopted by the people who use the arches. Then, after the situation has fully surfaced, the "beforehand"-clause would be satisfied. Only few modificaitons are actually needed, like a field "untested" or something to indicate a package hasn't been acted upon or verified since the automatic conversion. If a user finds a verified, he might be able to unverify a package or be requested to use the comments section.
In a generalized approach this could solve even more of the current issues mentioned with aur, if it would incrementalize by version, per-arch-diffs and per-taco-diffs... making pkgbuilds patchwork. :)
Is there an official consensus about this question? I was asked to include 'arm' to the architecture array in fish-shell-git. I have no problems with that, but want to conform to the general recommendations.
[2012-07-21 10:15:55 +0200] SanskritFritz:
Is there an official consensus about this question?
No.
I was asked to include 'arm' to the architecture array in fish-shell-git. I have no problems with that, but want to conform to the general recommendations.
I would do it and think you should too if this brings little to no maintenance burden.
participants (13)
-
Baptiste
-
Connor Behan
-
Gaetan Bisson
-
Hugo Osvaldo Barrera
-
Jelle van der Waa
-
Loui Chang
-
Martti Kühne
-
Phillip Smith
-
Rashif Ray Rahman
-
SanskritFritz
-
Seblu
-
Simon Gomizelj
-
Xyne