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

From: Natanael Copa <[email-masked]>
Date: Wed, 24 Nov 2010 09:48:17 +0100

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

-nc

---
Unsubscribe:  [email-masked]
Help:         [email-masked]
---

---

From: Timo Teräs <[email-masked]>
Date: Wed, 24 Nov 2010 10:57:15 +0200

> We will also need an "arch" variable since some packages might be arch

Debian has also 'any' and 'all' architectures.

'any' = builds on all supported achitecture, but produce separate
binaries for each of them

'all' = same binary runs on all platforms (=scripts and data only)

We might want to have something similar.

> compatible so we cannot remove the current files from their locations.

I have no strong feelings. It's just a preference pick. I believe
Debian and most others use $version/$arch approach. And obviously we can
just symlink the old paths to new locations.

> repository? Renaming packages at this point will require some work.

Probably not. We should embed the architecture in the header metadata,
though. And cowardly refuse to install mismatching architecture package.

> Other things we need resolve?

Would be also nice if shared the arch-independent binary packages.
As-in, the "all" packages would be built only once, and be kept in
common tree. This would save a bit on the disk.

- Timo

---

---

From: Natanael Copa <[email-masked]>
Date: Thu, 25 Nov 2010 13:33:35 +0100

> We might want to have something similar.

good point. yes. we need "any" and "all".

> just symlink the old paths to new locations.

Ok, looks like $version/$arch is the way to go. That would also not mess
up the previous releases' archives.

> though. And cowardly refuse to install mismatching architecture package.

yeah. sound like 'arch = x86|x86_64|all' in .PKGINFO. This should not be
to hard to implement. How do we check what arch target has?
--initdb=<arch> which does: echo $arch > /var/lib/apk/arch

> common tree. This would save a bit on the disk.

yes. im open on ideas how to implement that. Currently we have one
buildbox per supported version (currently v1.10, v2.0, v2.1 and edge) I
suppose it would be convenient to have x86_64 on separate build box. We
*can* ofcourse convert the vserver host build.alpinelinux.org to x86_64
and run 32 bit vserver guests under there, but it would be convenient
with a new build box.

hm...

so, lets say all vservers have a shared dir, /var/packages, like we have
now with distfiles, then we have a PKGDEST that is something
like: /var/packages/$pkgarch/$repo/ where $pkgarch is either 'x86',
'x86_64' or 'all' and we have an option in /etc/abuild.conf if we should
build packages marked with 'all' or not (so only one of the build
vservers builds it). But how do we handle build dependencies then? since
a dependency might be built by other arch build vserver?

Would you need 2 lines in /etc/apk/repositories:
$mirror/alpine/$version/$arch and $mirror/alpine/$version/all
or we simply symlink packages in all to each arch repo?

-nc

---

---

From: Natanael Copa <[email-masked]>
Date: Wed, 24 Nov 2010 11:50:57 +0100

> Other things we need resolve?

One more thing. Should we use /usr/lib64 or /usr/lib for x86_64? Even if
we support multilib in future we might want stuff things in /usr/lib32
and /usr/lib.

I originially thought we could symlink /usr/lib64 to /usr/lib but that
is not a good idea as it will confuse apk-tools. One package might
provide /usr/lib64/libfoo.so and other /usr/lib/libfoo.so. If we symlink
the dirs will apk-tools allow them overwrite each others files. We don't
want that.

I tried to put things in /usr/lib but gcc seems to insist in putting the
libstdc++, libgomp and other libs in /usr/lib/../lib64 and hardcode that
path in libtool files (*.la) so building c++ apps later breaks.

If we go for /usr/lib64 and no /usr/lib then we might need fix uclibc's
default search path and i assume there will be a bunch of packages that
needs --libdir fix.

-nc

---