Received: from out.migadu.com (out.migadu.com [91.121.223.63]) by nld3-dev1.alpinelinux.org (Postfix) with ESMTPS id 6D49D782C56 for <~alpine/devel@lists.alpinelinux.org>; Thu, 23 Jan 2020 20:01:49 +0000 (UTC) Received: (Migadu outbound); Thu, 23 Jan 2020 20:01:49 +0000 Authentication-Results: out.migadu.com; auth=pass (plain) Received: from wms0-eu-central.migadu.com (wms0-eu-central.migadu.com [139.162.159.86]) by out.migadu.com (Haraka/2.8.16) with ESMTPSA id BD005303-2551-48E2-A49B-18EDAE32D57D.1 envelope-from (authenticated bits=0) (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 verify=FAIL); Thu, 23 Jan 2020 20:01:48 +0000 MIME-Version: 1.0 Date: Thu, 23 Jan 2020 20:01:48 +0000 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: RainLoop/1.12.1 From: "Ariadne Conill" Message-ID: <3bb955181601ff5044eae6284ab99f2a@dereferenced.org> Subject: Let's talk more about apk-tools 3.0 To: ~alpine/devel@lists.alpinelinux.org, ~alpine/users@lists.alpinelinux.org DKIM-Signature: v=1;a=rsa-sha256;bh=xA4rt7DOKTYap9XChU4fg+dz32+AcE5EJF9akhCCNgY=;c=relaxed/simple;d=dereferenced.org;h=from:subject:date:to;s=default;b=rgLlcHLOK8DdPywN74CAXdhUk+BmR6n1iJc2gpTkWZ4Jyma4N87r89XRK+UWSS/XGNBeuXX1vK+vnN740qKbuGxkRHHomayAtbCNpWn6Sm9UX046oJhyByIPiuINI4y384XBGQhhZAmQ0fIhVNvD180M1S/axS9SdzoehehLjvI= Hello everyone,=0A=0AThe e-mail thread I wrote earlier about apk-tools cu= lminated in=0Aa fairly lengthy discussion in IRC, that I believe has been= quite=0Auseful.=0A=0AThe primary concern with risk management was figuri= ng out the=0Asafest way to handle migration from apk2 to apk3. I am plea= sed=0Ato report that we appear to have found a workable solution for=0Adi= stributions like Alpine to follow!=0A=0AThe conclusion that we have reach= ed consensus on is that apk3=0Ashould continue to support APKv2 packages = for some period of=0Atime. This allows for us to provide both an APKv2 a= nd APKv3=0Aindex referencing the APKv2 packages. By doing so, we can hav= e=0Aa seamless migration to apk-tools 3.0 in a safe way that allows=0Afor= testing.=0A=0AWhile we do not have the full details worked out quite yet= on=0Awhat a transition would ideally look like, a rough idea would=0Abe = something along these lines:=0A=0A1. apk-tools 3.0 is released to the tes= ting repository.=0A2. Users who opt into the testing repository could at = that=0A time opt into testing apk-tools 3 if they wish by adding=0A i= t as a tagged dependency (apk add apk-tools@testing).=0A3. apk-tools 3 us= es the APKv3 indices, while apk-tools uses=0A the legacy APKv2 indices.= =0A4. If apk-tools 3 is stable and APKv3 package support is=0A complete= d, it replaces legacy apk-tools in Alpine 3.12.=0A5. At some point down t= he road, we swap over to APKv3=0A packages and stop providing APKv2 ind= ices. We call that=0A release Alpine 4.0.=0A=0AIt is suggested that ot= her distributions use the same basic=0Amigration strategy.=0A=0AIn the ev= ent of a problem, we simply hold apk-tools 3.0=0Amigration from testing t= o main to a future release, such as=0AAlpine 3.13.=0A=0AAnother question = that has been asked is how apk-tools-static=0Awill be handled. The plan = there is to provide a signed=0Aapk-tools-static binary that Alpine and ot= her distributions=0Acan use for bootstrapping purposes. More details on = that=0Awill be available once we have a specific plan for it.=0A=0AThanks= everyone for your feedback!=0A=0AAriadne