Date: Wed, 20 Jan 2021 09:59:56 +0100
From: Natanael Copa <ncopa@alpinelinux.org>
To: maxice8 <thinkabit.ukim@gmail.com>
Cc: ~alpine/devel@lists.alpinelinux.org
Subject: Re: Implement versioned names for major libraries to ease upgrade
 process
Message-ID: <20210120095956.1a3caa26@ncopa-desktop.lan>
In-Reply-To: <86c7a81e-1640-7f82-9e13-dfdbe1aad07b@gmail.com>
References: <86c7a81e-1640-7f82-9e13-dfdbe1aad07b@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

On Sat, 12 Dec 2020 06:36:16 -0300
maxice8 <thinkabit.ukim@gmail.com> wrote:

> Hello,
> 
> Distros like Debian and Void Linux have packages for major version of 
> libraries include the major version in their pkgname (example: 
> libboost1.75).
> 
> I'd like to implement that for Alpine Linux.

This is requirement for all the libs in build-base, otherwise the old
version in use will prevent the new -dev package to be installed.

> 
> ## Benefits to Alpine
> 
> Ease the upgrade process of major libraries with lots of consumers (like 
> boost that has 127-ish consumers) by allowing 2 or more versions of a 
> library to be installed in parallel.
> 
> Consumers will no longer need to be rebuilt all at once as users can 
> have multiple versions of the library installed and will be slowly 
> switched over to the new version as consumers are rebuilt to use the new 
> soname.

This may also create problems. What I am afraid of that we end up with
3 different version of boost in stable branches. And a single CVE needs
to be fixed in 3 * 5 branches (4 stable + edge). It means that every
single CVE needs to fixed in 15 packages.


> This is already done for llvm which breaks API and ABI every MAJOR 
> release so we keep llvmN and llvmN+1 and remove llvmN once all packages 
> are switched over to use llvmN+1.

The reason for llvm was that some packages requires a specific, often
older, version of llvm. For example crystal.

We actually have a problem now because chromium 87 seems to require
llvm-11, which we dont have for 3.13-stable.

> 
> ## Drawbacks
> 
> More APKBUILDs will need to be maintained until the whole process is
> done.
> 
> If we depend on foo-dev with foo-dev being claimed by the latest
> version of foo, it becomes possible for some packages to be missed
> during the upgrade process and never processed until the older foo is
> removed.
> 
> Otherwise if we decide on depending on fooX-dev directly then it 
> increases work on upgrading packages but guarantees no package will
> be missed in the way mentioned above.
> 
> People might start manually installing fooX instead of installing foo 
> and just getting the latest version and then their system **could 
> possibly** break during an upgrade.
> 
> ## Workflow
> 
> First time:
> 
> 1. Upstream releases a new major version
> 2. New aport is created that has pkgname that includes the major
> version and claims common subpackages (-dev, -doc, -openrc,
> -*sh-completion, etc) via provides="foo-dev=$pkgver-r$pkgrel".

provides="foo-dev=$pkgver-r$pkgrel" will not work.

You need subpackages="foo-dev". The reason is that otherwise it will be
impossible to calculate the build order until after the build is done.

The build order calculator needs to know how to find foo-dev, and it
cannot do that if it is a provides in a split function.

Have a look at mpfr/mpfr3/mpfr4 git history for an example.

> 3. Consumers are rebuilt all at once (for the last time)
> 4. the old aport is removed
> 
> All following times:
> 
> 1. Upstream release a new major version
> 2. New aport is created that has pkgname that includes the major
> version and claims common subpackages (-dev, -doc, -openrc,
> -*sh-completion, etc) via provides="foo-dev=$pkgver-r$pkgrel".
> 3. Old aport is rebuilt without the provides=
> 4. Consumers are rebuilt as possible/expedient
> 5. old aport is removed
> 
> ## Timeline
> 
> This will be implemented as soon as 3.13 is released and consensus is 
> reached (assuming it is positive)
> 
> Regards
> Leo