X-Original-To: alpine-devel@lists.alpinelinux.org Delivered-To: alpine-devel@mail.alpinelinux.org Received: from dal-a2.localdomain (unknown [74.117.189.115]) by mail.alpinelinux.org (Postfix) with ESMTP id 5BF4EDC00AE for ; Mon, 6 Jan 2014 16:18:21 +0000 (UTC) Received: from ncopa-desktop.alpinelinux.org (3.203.202.84.customer.cdi.no [84.202.203.3]) (using SSLv3 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: ncopa@tanael.org) by dal-a2.localdomain (Postfix) with ESMTPSA id BA7DABC1205 for ; Mon, 6 Jan 2014 16:18:20 +0000 (UTC) Date: Mon, 6 Jan 2014 17:18:17 +0100 From: Natanael Copa To: alpine-devel@lists.alpinelinux.org Subject: [alpine-devel] using x86 apkovl on x86_64 and vice versa Message-ID: <20140106171817.0ebe90e3@ncopa-desktop.alpinelinux.org> X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.20; x86_64-alpine-linux-uclibc) X-Mailinglist: alpine-devel Precedence: list List-Id: Alpine Development List-Unsubscribe: List-Post: List-Help: List-Subscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hi, This is basically http://bugs.alpinelinux.org/issues/2529 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 ---