Add support for aarch64

[Mike Frysinger]

On Monday 13 May 2013 22:01:59 Christopher Meng wrote:
> Mike, actually I don't want to discuss it here, I think it's not a good
> place. IMO AArch64 is too young to introduce it. When I started my
> packaging life there is no such arch.

aarch64 is incidental.  this problem has been affecting people pretty much 
since config.{sub,guess} started being redistributed.  the initial x86_64 port 
went through the same growing pains, as has every person that has released a 
new cpu (tends to be more of an "embedded problem").

> You may noticed that from 2013 there are many such requests appeared, all
> of them have same content and a patch automatically generated by a script.
> That's what Red Hat people are doing,  in fact about 1800 packages have
> received such request. I cannot say this is right or wrong,  solving the
> problem may via many ways.

as soon as you hassle upstream, you're doing it wrong imo.  i have seen the 
same request in various projects i'm incidentally subscribed to and rebuffed 
each one.

> AArch64 is an new arch we finally have to face. I know what you want to
> express, In fact it's true that we cannot ask every upstream to update
> their config. I use autoreconf to reconfigure, but sometimes
> it cannot solve the problem. So I consider a request at upstream. Applying
> such a big patch is cumbersome, and of course ridiculous.

patching & autoreconf are both unnecessary.  just copy config.{sub,guess} from 
a common system location and blam, you're fixed the vast majority of packages.  
the only time you need to hassle upstream is when they have custom code that 
actually does target detection (but those tend to be on the uncommon side).

> Some developers at SUSE have already discussed the problem of this. They
> want to fix it by patching the RPM as you expected. But I don't know the
> progress now, and in Fedora there is no such patch available now, and maybe
> for a while.
> 
> Red Hat people threw out a point:
> 
> http://lists.fedoraproject.org/pipermail/devel/2013-April/181055.html

yes, i made a similar point on the acl lists (coincidentally just a few days 
before that fedora post):
http://lists.nongnu.org/archive/html/acl-devel/2013-04/msg00003.html

trying to hoist package manager limitations onto every upstream project is 
poor form.  the fact that implementing a proper fix is taking time isn't really 
a valid reason.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20130513/a5d1540c/attachment.pgp