To: ~alpine/devel@lists.alpinelinux.org
From: maxice8 <thinkabit.ukim@gmail.com>
Subject: Implement versioned names for major libraries to ease upgrade process
Message-ID: <86c7a81e-1640-7f82-9e13-dfdbe1aad07b@gmail.com>
Date: Sat, 12 Dec 2020 06:36:16 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.5.1
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 7bit

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.

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.

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".
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