FS#19753 - [makepkg] Add some portable source otion to arch=(). Make ArchLinux portable!
Attached to Project:
Pacman
Opened by Tomas Mudrunka (harvie) - Wednesday, 09 June 2010, 13:45 GMT
Last edited by Allan McRae (Allan) - Wednesday, 16 June 2010, 06:58 GMT
Opened by Tomas Mudrunka (harvie) - Wednesday, 09 June 2010, 13:45 GMT
Last edited by Allan McRae (Allan) - Wednesday, 16 June 2010, 06:58 GMT
|
Details
Summary and Info:
Right now most of PKGBUILDs are using one of those two lines: arch=('i686' 'x86_64') arch=('any') but if i have some well written portable source. eg: #include <stdio.h> int main(void) { puts("hello"); } /*or something more complex... */ i can compile it on almost any architecture imaginable and on any architecture where gcc is available. i can't use arch=('any'), because it means binary portability, but what should i say for source portability? IMHO there should be one more option. Archlinux have thousands of packages with arch=('i686' 'x86_64') so if i will want to port them for example on som MIPS(EL) or ARM i will need to fix all those PKGBUILDs. Why packages are not just using something like arch=("$CARCH") or some lingo like carch, gnu, portable or something similar what will be replaced by $CARCH in makepkg... It should be nice if ArchLinux can have majority of PKGBUILDS common for all architectures and ports. so i can just take ABS tree and build it on MIPS router, ARM PDA or i686 PC with GNU/HURD... i guess changing all packages to arch=("$CARCH") if they can build with it is a good start... if you don't like this idea, please discuss it and think about it for a while. i think it's not arch-way to have magicaly hardcoded whitelist of architectures in each source package... (especially if we know that it's not final). Today people like i686 and x86_64, but it's just some kind of trend or fashion and i hope there will come better architectures in (distant) future. |
This task depends upon
Closed by Allan McRae (Allan)
Wednesday, 16 June 2010, 06:58 GMT
Reason for closing: Won't implement
Additional comments about closing: See comments
Wednesday, 16 June 2010, 06:58 GMT
Reason for closing: Won't implement
Additional comments about closing: See comments
* Allan- how many of the Arch Linux PKGBUILDs could be ported to Arch Hurd without a single modification?
* How many changes and tweaks and patches do we have to apply to get things working right for both architectures?
* We have enough bug reports already dealing with two architectures, adding an unknown more would be a nightmare.
> * How many changes and tweaks and patches do we have to apply to get things working right for both architectures?
> * We have enough bug reports already dealing with two architectures, adding an unknown more would be a nightmare.
in such cases you just will not use such specification of arch source independence
While a different operating system is perhaps a tough example, we do currently require patches for only i686 or x86_64. The ppc guys have their own set, as to the arm guys.
But the real reason I am against this is that the "arch" array shows what architectures the PKGBUILD is _known_ to work on (ignoring different OS...). Nobody knows that a package of any complexity works on every architecture without testing it.
And, if you really want to assume that all packages work for a new architecture, just grab the ABS tree and it is a single line command involving find and sed to fix it.