Precedence: list
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8;
 format=flowed
Content-Transfer-Encoding: 7bit
Date: Fri, 10 Jan 2014 15:48:10 -0600
From: elactrum@jamailca.com
To: <alpine-devel@lists.alpinelinux.org>
Subject: Re: [alpine-devel] using x86 apkovl on =?UTF-8?Q?x=38=36=5F=36=34?=
 =?UTF-8?Q?=20and=20vice=20versa?=
In-Reply-To: <20140106171817.0ebe90e3@ncopa-desktop.alpinelinux.org>
References: <20140106171817.0ebe90e3@ncopa-desktop.alpinelinux.org>
Message-ID: <a9a70d8acfde74e6dd3da202aba27d74@qcslink.com>
User-Agent: Roundcube Webmail/0.8.5

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?
-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
---