Date: Fri, 24 Jan 2020 05:57:43 +0200
From: Timo Teras <timo.teras@iki.fi>
To: "Ariadne Conill" <ariadne@dereferenced.org>
Cc: ~alpine/devel@lists.alpinelinux.org,
 ~alpine/apk-tools@lists.alpinelinux.org
Subject: Re: Let's talk more about apk-tools 3.0
Message-ID: <20200124055743.192aec49@vostro>
In-Reply-To: <43397dfce7287c7ea51d04ba0d47d81c@dereferenced.org>
References: <43397dfce7287c7ea51d04ba0d47d81c@dereferenced.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Hi,

I'm still replying to both lists, but will in future start to use the
apk-tools list. Those interested in apk-tools discussion should
subscribe now to the apk-tools mailing list if not done yet so.

On Thu, 23 Jan 2020 20:02:41 +0000
"Ariadne Conill" <ariadne@dereferenced.org> wrote:

> The e-mail thread I wrote earlier about apk-tools culminated in
> a fairly lengthy discussion in IRC, that I believe has been quite
> useful.

Yes. My apologies also on not describing well enough the intended
migration path. So far I've been just trying to describe the end
result. But at no point I have had desire to do day 0 transition when
everything changes without any backward compatibility.

> The primary concern with risk management was figuring out the
> safest way to handle migration from apk2 to apk3. I am pleased
> to report that we appear to have found a workable solution for
> distributions like Alpine to follow!
> 
> The conclusion that we have reached consensus on is that apk3
> should continue to support APKv2 packages for some period of
> time. This allows for us to provide both an APKv2 and APKv3
> index referencing the APKv2 packages. By doing so, we can have
> a seamless migration to apk-tools 3.0 in a safe way that allows
> for testing.

Yes. This has been my desire all along to do incremental -wip or -rc
releases in testing with opt-in installation.

Maybe the biggest take away from the discussion was to do first the
index conversion and only later the package format changes. Which
sounds reasonable path.

> While we do not have the full details worked out quite yet on
> what a transition would ideally look like, a rough idea would
> be something along these lines:
> 
> 1. apk-tools 3.0 is released to the testing repository.
> 2. Users who opt into the testing repository could at that
> time opt into testing apk-tools 3 if they wish by adding
> it as a tagged dependency (apk add apk-tools@testing).
> 3. apk-tools 3 uses the APKv3 indices, while apk-tools uses
> the legacy APKv2 indices.

We'll provide "apk migrate" or similar to convert the current installed
db to the new format. And given the scope of things, it'll probably be
worth the work to have "apk migrate --version=2" or similar to roll back
for the old format -- at least for the duration of the development and
stabilazation work.

> 4. If apk-tools 3 is stable and APKv3 package support is
> completed, it replaces legacy apk-tools in Alpine 3.12.
> 5. At some point down the road, we swap over to APKv3
> packages and stop providing APKv2 indices. We call that
> release Alpine 4.0.
> 
> It is suggested that other distributions use the same basic
> migration strategy.
> 
> In the event of a problem, we simply hold apk-tools 3.0
> migration from testing to main to a future release, such as
> Alpine 3.13.
> 
> Another question that has been asked is how apk-tools-static
> will be handled. The plan there is to provide a signed
> apk-tools-static binary that Alpine and other distributions
> can use for bootstrapping purposes. More details on that
> will be available once we have a specific plan for it.
> 
> Thanks everyone for your feedback!

Thank you!