Mail archive

[alpine-devel] Dealing with multiple architectures (x86/x86_64)

From: Natanael Copa <>
Date: Wed, 24 Nov 2010 09:48:17 +0100


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...";;

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 <arch> 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?


Received on Wed Nov 24 2010 - 09:48:17 UTC