Message-ID: <94c410addef602fe65ccc485c4400e65c9962718.camel@gmail.com>
Subject: Re: Implement versioned names for major libraries to ease upgrade
 process
From: maxice8 <thinkabit.ukim@gmail.com>
To: Natanael Copa <ncopa@alpinelinux.org>
Cc: ~alpine/devel@lists.alpinelinux.org
Date: Wed, 20 Jan 2021 06:52:17 -0300
In-Reply-To: <20210120095956.1a3caa26@ncopa-desktop.lan>
References: <86c7a81e-1640-7f82-9e13-dfdbe1aad07b@gmail.com>
	 <20210120095956.1a3caa26@ncopa-desktop.lan>
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.38.2 (3.38.2-1.module_f33+10736+4f8d5006) 
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit

On Wed, 2021-01-20 at 09:59 +0100, Natanael Copa wrote:
> 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.
> 

Ok

> > 
> > ## 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.
> 

I don't expect that to happen, the creation of versioned names isn't
meant for the user, it is explicitly meant for us (maintainers) to have
some time (a few days to weeks, maybe up to a month if we find a
particularly uncooperative upstream) to properly rebuild everything.

The last rebuild of boost 1.69.0->1.75.0 kept me awake all night fixing
stuff and it still technically isn't done because mkvtoolnix is failing
in one arch.

I am drafting an E-Mail about expected downtime while I upgrade python3
to 3.9.1 (which breaks modules with 3.8.1).

> 
> > 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.
> 

The reason is not of much relevance, what is relevant is that we have
some basic experience in versioned packages.

> > 
> > ## 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.
> 

That is good to know and it means boost1.75 is busted, I'll make a fix
merge request.