X-Original-To: alpine-devel@lists.alpinelinux.org Delivered-To: alpine-devel@lists.alpinelinux.org Received: from mail.wtbts.no (mail.wtbts.no [213.234.126.131]) by lists.alpinelinux.org (Postfix) with ESMTP id 155061EB587 for ; Wed, 24 Nov 2010 08:48:19 +0000 (UTC) Received: from [10.65.65.1] (unknown [10.65.65.1]) by mail.wtbts.no (Postfix) with ESMTP id 38AE97E0C1 for ; Wed, 24 Nov 2010 09:40:41 +0100 (CET) Subject: [alpine-devel] Dealing with multiple architectures (x86/x86_64) From: Natanael Copa To: Alpine Development Content-Type: text/plain; charset="UTF-8" Date: Wed, 24 Nov 2010 09:48:17 +0100 Message-ID: <1290588497.6958.21.camel@ncopa-desktop.nor.wtbts.net> X-Mailinglist: alpine-devel Precedence: list List-Id: Alpine Development List-Unsubscribe: List-Post: List-Help: List-Subscribe: Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 Content-Transfer-Encoding: 7bit Hi, So we are in the progress of porting Alpine Linux to x86_64. We have a native compiler (but needs a bit cleanup), we have a handful of patches for uclibc that needs a bit cleanup and made sure they gets included in upstream (official uclibc) and we have a couple of bugfixes for apk-tools. Basicly, the x86_64 port is up and running, more or less. I have a few pending changes for abuild comming up. Future versions of abuild will require that you set CARCH, CBUILD, CHOST, CTARGET and ALPINE_LIBC (uclibc/eglibc). I'm not sure we need the ALPINE_LIBC variable since we can extract that info from CHOST: case "$CHOST" in *-uclibc) msg "uclibc...";; *-gnu) msg "glibc/eglibc...";; esac We will also need an "arch" variable since some packages might be arch specific. For example: arch="x86 x86_64" We also need to figure out how to deal with the infrastructure. Mirrors: How do we organize the archives? Should we put things in $mirror/alpine/$arch/$version/stuff or $mirror/alpine/$version/$arch/stuff? I think we want be backwards compatible so we cannot remove the current files from their locations. apk-tools: Should we (re)name the package file names? foo-1.0-r0-x86.apk vs foo-1.0-r0-x86_64.apk? Or should we do what OpenBSD does, keep the arch out from the filename and let users make sure they use the proper repository? Renaming packages at this point will require some work. Bugtracker: we need add info about reported bugs. Does Redmine support that? Maintainers: How do we organize things for package maintainers? should the package maintainer be reponsible for all archs? or should we have arch maintainers? Other things we need resolve? -nc --- Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org Help: alpine-devel+help@lists.alpinelinux.org ---