From: Ariadne Conill <ariadne@dereferenced.org>
To: ~alpine/devel@lists.alpinelinux.org
Cc: maxice8 <thinkabit.ukim@gmail.com>
Subject: Re: Implement versioned names for major libraries to ease upgrade process
Message-ID: <6228113.OPkDe4bAzH@nanabozho>
In-Reply-To: <86c7a81e-1640-7f82-9e13-dfdbe1aad07b@gmail.com>
References: <86c7a81e-1640-7f82-9e13-dfdbe1aad07b@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
Date: Sat, 12 Dec 2020 10:36:46 GMT


On Saturday, December 12, 2020 2:36:16 AM MST maxice8 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).

We already do this with some libraries.  I think it would be good to make it 
standard practice.

> 
> I'd like to implement that for Alpine Linux.
> 
> ## 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 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.
> 
> ## 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.

One solution here would be for fooX-dev to also provide foo-dev=X.  This will 
cause abuild to pull in the newest package if possible.

> 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.

It should be fine, as the dependencies are against so:libfoo.so.X and not 
actually against fooX.

Ariadne