DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject
         :references:in-reply-to:x-enigmail-version:content-type
         :content-transfer-encoding;
        b=jpt0F+SNpNBuszkzAGqTNCSpMFgwuJzt2Og/TnSbwtNvRR2qbqUPWvQdW4xwF/faLm
         4lf7ojvIYyDJtf+jmqKpQrkYyNnW3cETV22z76ezErVi2yInF7muPdERNqui/9u/Bf2v
         jCsiv2rRhAugavz/8zAbCMRxqdH2EmS7Ye/No=
Sender: =?UTF-8?Q?Timo_Ter=C3=A4s?= <timo.teras@gmail.com>
Message-ID: <4CECD36B.7050301@iki.fi>
Date: Wed, 24 Nov 2010 10:57:15 +0200
From: =?UTF-8?B?VGltbyBUZXLDpHM=?= <timo.teras@iki.fi>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6
Precedence: list
MIME-Version: 1.0
To: Natanael Copa <ncopa@alpinelinux.org>
CC: Alpine Development <alpine-devel@lists.alpinelinux.org>
Subject: Re: [alpine-devel] Dealing with multiple architectures (x86/x86_64)
References: <1290588497.6958.21.camel@ncopa-desktop.nor.wtbts.net>
In-Reply-To: <1290588497.6958.21.camel@ncopa-desktop.nor.wtbts.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 11/24/2010 10:48 AM, Natanael Copa wrote:
> We will also need an "arch" variable since some packages might be arch
> specific. For example:
> 
> arch="x86 x86_64"

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.

> 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.

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.

> 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.

Probably not. We should embed the architecture in the header metadata,
though. And cowardly refuse to install mismatching architecture package.

> 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?

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


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---