Through searching, I've found discussions about people adding unsupported architectures (specifically arm and ppc) to their current i686/x86_64 PKGBUILDs. Nobody has a problem with that (I don't, either). What I haven't found is any discussion about packages that are *exclusively* for one of these architectures. Is this something that's allowed or not?
Doug
Good question. One of my packages got deleted last year because it was arm only. I no longer used any arm systems, and was just maintaining it, so I didn't bother chasing it up. But I'm also interested in the answer to that.
Regards, Justin Dray E: justin@dray.be M: 0433348284
The wiki page on PKGBUILDs [1] gives me the strong impression it *has* to be at least i686 and/or x86_64. To quote it:
Currently, it [the arch field] should contain i686 and/or x86_64
It goes on to mention that the 'any' pseudo-architecture can be used for platform independent packages. So in theory, if it doesn't contain i686, x86_64 or any, it's not allowed. The key word here is 'contain'. The most common interpretation of this word makes it synonymous with 'include'. This means that you are allowed to have 'arch=(i686 armv5h)' or 'arch=(i686 x86_64 armv5h)' but not solely 'arch=(armv5h)'.
...as I (not unreasonably) interpret it.
On Thu, Nov 20, 2014 at 11:31 PM, Justin Dray justin@dray.be wrote:
Good question. One of my packages got deleted last year because it was arm only. I no longer used any arm systems, and was just maintaining it, so I didn't bother chasing it up. But I'm also interested in the answer to that.
I think ARM-only packages should be tolerated on the AUR, simply because AUR is the place where people look for PKGBUILDs.
On that same note, I'm completely fine with all archs' archers' notion that ARM users should be using makepkg -Ai.
cheers! mar77i
I think ARM-only packages should be tolerated on the AUR, simply because AUR is the place where people look for PKGBUILDs.
That is actually a fair point, and I agree with you. But we do have to keep in mind that Archlinux ARM is a completely different project, and you're using archlinux.org's server space and data cap when you submit AUR packages.
I wonder how opinions on this matter would change if ten thousand arm-only packages were dropped on the AUR overnight?
On Fri, Nov 21, 2014 at 10:41 AM, David Phillips dbphillipsnz@gmail.com wrote:
I wonder how opinions on this matter would change if ten thousand arm-only packages were dropped on the AUR overnight?
What are the odds of that happening? Also, how could a further decision not handle that case at said point? Architecture-specific software has been a niche for almost decades now since cpus became satisfyingly fast to run compiled code. Maybe I just personally don't use assembly widely enough and hence don't see the problem.
cheers! mar77i
I wonder how opinions on this matter would change if ten thousand arm-only packages were dropped on the AUR overnight?
What are the odds of that happening? Also, how could a further decision not handle that case at said point? Architecture-specific software has been a niche for almost decades now since cpus became satisfyingly fast to run compiled code. Maybe I just personally don't use assembly widely enough and hence don't see the problem.
cheers! mar77i
i think, arm-only packages (as well as other unofficial architectures) should stay out of AUR. the current state is that almost all packages i encounter as a normal arch user are principially runnable for me. this looks different from an arm perspective. for them, most packages are not usable and it depends on their luck and work, to get things building. if we allow more non-official architecture packages in the AUR, the situation will not improve very much for the unofficial archs. but for conventional arch users, it becomes much more likely to encounter a package that does simply not build on their architecture. since AUR is open source, other architectures should use an own setup, to keep things clean and userfriendly. this means some more administration work, but i think, this provides best usability for all users. the word package here means tarball from the AUR. thanks for considering.
On 21-11-14 10:51, Martti Kühne wrote:
Architecture-specific software has been a niche for almost decades now since cpus became satisfyingly fast to run compiled code. Maybe I just personally don't use assembly widely enough and hence don't see the problem. cheers! mar77i
Martti,
the problem is not assembly in the source code, , but the fact that all compilers deliver machine-specific code . compile a C program on an arm processor, try to run the binary on a x86 processor. It will fail always.
Only languages that compile into a crossplatform format like java bytecode can run on all platforms. Interpreted languages like bash and python also should work on all platforms.
TL;DR : sourcecode can be platform indepent , binaries are always architecture specific.
Lone_Wolf
On Fri, Nov 21, 2014 at 12:58 PM, LoneVVolf lonewolf@xs4all.nl wrote:
Martti,
the problem is not assembly in the source code, , but the fact that all compilers deliver machine-specific code . compile a C program on an arm processor, try to run the binary on a x86 processor. It will fail always.
I am perfectly aware. I'm sure I was addressing the general case of *using* architecture-specific code in the source state, which is where a PKGBUILD would start off where that would be an issue. Thanks however for clarifying this again.
* David Phillips dbphillipsnz@gmail.com (Fri, 21 Nov 2014 22:41:14 +1300):
I think ARM-only packages should be tolerated on the AUR, simply because AUR is the place where people look for PKGBUILDs.
That is actually a fair point, and I agree with you. But we do have to keep in mind that Archlinux ARM is a completely different project, and you're using archlinux.org's server space and data cap when you submit AUR packages.
I'm rather indifferent, though I expect that packages build on my architecture (x86_64), which is not the case for ARM-only packages.
That said, I wonder why Arch Linux ARM, which *is* a different project, doesn't provide its own AUR? Wouldn't that be a solution for ARM-only packages? And perhaps providing a link to "our" AUR (or even an iframe) for packages that build also on i686/x86_64? Just a thought.
Regards, Marcel
On Fri, Nov 21, 2014 at 02:14:53PM +0100, Marcel Korpel wrote:
That said, I wonder why Arch Linux ARM, which *is* a different project, doesn't provide its own AUR? Wouldn't that be a solution for ARM-only packages?
This was my first thought. There isn't a reason for arm-only packages to be in the AUR. But preventing listing arm as an option along with i686 or x86_64 would seem just spiteful and silly. So I thought allowing any PKGBUILD that at least builds for either supported architecture would be fine, and additional architectures would be no issue at all. While any PKGBUILDs that are for arm only should be kept somewhere else.
But then this might be a hassle for arm users - now they need to check two different places for these PKGBUILDs.
I'm doubtful that the 'server burden' of keeping the rare arm-only PKGBUILD is noteworthy. The benefit to being good cooperative members of an open-source community by allowing these rare arm-only PKGBUILDs would be noteworthy.
I'd love to benefit from PKGBUILDs made by arm users when they could also build just fine on my x86_64. Why duplicate effort when a majority of packages that would work on one would work on the other.
-Jesse AKA 'Trilby' on archlinux.org
2014-11-21 12:39 GMT-03:00 Jesse McClure jmcclure@cns.umass.edu:
On Fri, Nov 21, 2014 at 02:14:53PM +0100, Marcel Korpel wrote:
That said, I wonder why Arch Linux ARM, which *is* a different project, doesn't provide its own AUR? Wouldn't that be a solution for ARM-only packages?
This was my first thought. There isn't a reason for arm-only packages to be in the AUR. But preventing listing arm as an option along with i686 or x86_64 would seem just spiteful and silly. So I thought allowing any PKGBUILD that at least builds for either supported architecture would be fine, and additional architectures would be no issue at all. While any PKGBUILDs that are for arm only should be kept somewhere else.
But then this might be a hassle for arm users - now they need to check two different places for these PKGBUILDs.
I'm doubtful that the 'server burden' of keeping the rare arm-only PKGBUILD is noteworthy. The benefit to being good cooperative members of an open-source community by allowing these rare arm-only PKGBUILDs would be noteworthy.
I'd love to benefit from PKGBUILDs made by arm users when they could also build just fine on my x86_64. Why duplicate effort when a majority of packages that would work on one would work on the other.
-Jesse AKA 'Trilby' on archlinux.org
Spiteful or silly, aur packages has ben removed because they contain arm thing, so if you will do it, be carrefull that the: "Currently, it [the arch field] should contain i686 and/or x86_64" could be interpreted by other user and TUs as "only ARCH supported in AUR" and therefor submit a delete request.
the only 100% safe aproach is that the Wiki or the Aur page state the official status about those architectures in AUR.
aur-general@lists.archlinux.org