Date: Sun, 12 Jan 2014 21:11:18 +0100
From: Natanael Copa <ncopa@alpinelinux.org>
To: elactrum@jamailca.com
Cc: <alpine-devel@lists.alpinelinux.org>
Subject: Re: [alpine-devel] using x86 apkovl on x86_64 and vice versa
Message-ID: <20140112211118.425e14e5@ncopa-desktop.alpinelinux.org>
In-Reply-To: <a9a70d8acfde74e6dd3da202aba27d74@qcslink.com>
References: <20140106171817.0ebe90e3@ncopa-desktop.alpinelinux.org>
	<a9a70d8acfde74e6dd3da202aba27d74@qcslink.com>
Precedence: list
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

On Fri, 10 Jan 2014 15:48:10 -0600
elactrum@jamailca.com wrote:

> On 2014-01-06 10:18, Natanael Copa wrote:
> > Hi,
> > 
> > This is basically http://bugs.alpinelinux.org/issues/2529
> > 
> 
> Looks like issue 2529 is now closed. Which option did you choose?

I ended up with option 1.

> -elactrum
> 
> > Problem: if generated an apkovl on x86, copy that apkovl to x86_64, it
> > will fail to boot. It might be handy to convert a 32bit system to
> > 64bit. (or to arm when that is possible)
> > 
> > I can see 2 possible options:
> > 
> > 1) It just happens automatic.
> >    the init script detects the mismatch and silently just fixes it for
> >    user.
> > 
> >    benefits:
> >    * things just works. just copy the apkovl and reboot. job done.
> > 
> >    drawbacks:
> >    * it might be unintentional. If user intended to upgrade a 64bit
> >      install to a new 64bit but by mistake did it 32 bit, the mistake
> >      will be discovered late, if all. (the production system fails
> >      weeks later due to out of memory even if you had 16GB ram...)
> > 
> > 
> > 2) Display error message and fail if config arch mismatch unless boot
> >    option given. If use wants switch architecture he will need 
> > explicit
> >    give a boot option (maybe update_apk_arch?) and the arch will be
> >    updated automatically. The error message could tell about the boot
> >    option.
> > 
> >    benefits:
> >    * Alpine don't try to be smart. User is in full control.
> > 
> >    * we fail early in case the change was unintentional.
> > 
> >    drawbacks:
> >    * User might be doing remote upgrade and might not have access to
> >      boot console. So user need remember to manually edit the
> >      syslinux.cfg to not lose the remote box - and edit it back after
> >      reboot.
> > 
> > 
> > Both are equally easy to implement.
> > I am in favor of option #2 (I like the don't-try-to-be-too-smart way 
> > of
> > think)
> > 
> > Keep in mind that even it unlikely, there might be some apps that have
> > arch specific configuration.
> > 
> > What do you think?
> > 
> > Are there other things I might have missed?
> > 
> > Thanks!
> > 
> > 
> > ---
> > Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
> > Help:         alpine-devel+help@lists.alpinelinux.org
> > ---
> 
> 
> ---
> Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
> Help:         alpine-devel+help@lists.alpinelinux.org
> ---
> 



---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---