From: Ariadne Conill <ariadne@dereferenced.org>
To: ~alpine/devel@lists.alpinelinux.org
Subject: Re: Implement versioned names for major libraries to ease upgrade process
Message-ID: <12680118.cB5P6ohCNs@nanabozho>
In-Reply-To: <e0242ec7182e8cf12eae9f14ed142fd25621d780.camel@cogitri.dev>
References: <86c7a81e-1640-7f82-9e13-dfdbe1aad07b@gmail.com> <e0242ec7182e8cf12eae9f14ed142fd25621d780.camel@cogitri.dev>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
Date: Sat, 12 Dec 2020 10:52:13 GMT


On Saturday, December 12, 2020 3:38:44 AM MST Rasmus Thomsen wrote:
> Hello,
> 
> On Sat, 2020-12-12 at 06:36 -0300, 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).
> > 
> > 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.
> 
> Hm, I think the only time users interact with major libraries upgrades
> are on edge or if they upgrade between major versions. As such I don't
> think the effort/maintaince overhead versioned libraries introduce is
> worth it just to not break edge during rebuilds of big packages like
> boost.
> 
> One thing that might be interesting about having versioned names for
> libraries would be that it would make using edge packages on stable
> releases less broken, but if we only do it for major libraries it'd
> still be pretty broken for packages which use un-versioned libraries.

Adopting versioning practice for libraries we choose to not have multiple 
versions of is still valuable because we can immediately provide new versions 
of the library in the futue without breaking anything.

> 
> > [...]
> > 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.
> 
> I think we only do this for LLVM because packages tend to take a long
> time before they switch over to new LLVM versions because it's so much
> effort to stay on top of LLVM effort.

We also do this with GTK+ because some programs want GTK+2, others want GTK+3 
and others want GTK+4.  We also did this with Qt 4 vs Qt 5 for a long time, 
and we will probably do this with Qt 5 vs Qt 6 for some time too.

Ariadne