Subject: Re: Implement versioned names for major libraries to ease upgrade
 process
To: Ariadne Conill <ariadne@dereferenced.org>,
 ~alpine/devel@lists.alpinelinux.org
References: <86c7a81e-1640-7f82-9e13-dfdbe1aad07b@gmail.com>
 <6228113.OPkDe4bAzH@nanabozho>
From: maxice8 <thinkabit.ukim@gmail.com>
Message-ID: <d06281e3-715f-a8a9-1017-0535d3bcd54b@gmail.com>
Date: Sat, 12 Dec 2020 08:12:00 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.5.1
MIME-Version: 1.0
In-Reply-To: <6228113.OPkDe4bAzH@nanabozho>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit

Hello

On 12/12/20 7:36 AM, Ariadne Conill wrote:
> 
> 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.
> 

Can be as long as there aren't multiple versions laying around, the 
express purpose is to ease the burden of upgrading major libraries with 
lots of consumers like boost.

>>
>> 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.
> 

That is the way of the paragraph above, if we decide on foo-dev we can 
miss a package, if we pick fooX-dev then we will never miss a package 
because we just have to move all fooX-dev to fooY-dev.

Another problem is the dependency ordering if we don't queue the builds 
carefully some packages won't be rebuilt properly (talking from 
experience on Void Linux).

>> 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.
> 

It is more about the possibility of something funky happening when 
upgrading with deleted packages, I have no clue if there is any actual 
problem but I'm staying on the safe side.

Regards,
Leo