I agree with your sentiments, based upon several informal discussions I 
have had with CentOS 8 "adopters".  "Supported" RHEL 8 seems to be 
better -- but are there still issues with EPEL, etc., because of 
inappropriate sub-system designations (as with the python example you 
provide)?  From what I can tell, Ubuntu LTS is a bit more "adaptable". 
Given the tool set and source partitions you describe, fortunately, I 
currently am not porting from source, and compile applications from 
source only when the "source" has a specification for the actual distro 
release that I use.

On 12/8/20 7:11 PM, Nico Kadel-Garcia wrote:
> On Tue, Dec 8, 2020 at 9:31 PM Konstantin Olchanski <[log in to unmask]> wrote:
>>
>> On Tue, Dec 08, 2020 at 04:39:32PM -0800, Patrick J. LoPresti wrote:
>>>
>>> It has been almost exactly seven years since Red Hat bought CentOS
>>>
>>
>> The way I remember it, RedHat approached CentOS lead developers and
>> made them an offer they could not refuse.
>>
>>>
>>> Very curious how CERN and Fermilab will respond to this.
>>>
>>
>> Nothing from CERN yet. But to sense where the wind is blowing,
>> note how ROOT still do not provide a binary kit for CentOS-8.
>> https://root.cern/releases/release-62206/
> 
>> Our experiment at CERN (ALPHA anti-hydrogen trapping and spectroscopy)
>> uses CentOS-7 and we are in discussions over upgrading to CentOS-8
>> or Ubuntu LTS 20.04. All our RaspberyPi machines will probably
>> become converted from CentOS-7 to Raspbian (Ubuntu/Debian). For DAQ and
>> analysis machines, there is a preference for CentOS-8, but if we they
>> tell us now that CentOS-8 is a dead end and in 1 year will will have
>> to upgrade *again*, Ubuntu may become the preferred solution.
> 
> I'm unhappy with CentOs 8. The primary python 3 is already obsolete,
> python 3.6, and should have been published as "python36" rather than
> "pythone3" to allow a compatible "python38" parallel upgrade path.
> Unfortunately, they've convinced EPEL as well to name packages
> "python3" for "python36" packages in EPEL 7 and EPEL 8.  Guess what
> fun this causes over in the Amazon Linux world, where "python3" is
> "python37" and python modules from EPEL can no longer be used safely.
> 
> Do not get me *started* on "modular RPMs", which have proven very
> destabilizing for building anything, for which there is no usable
> documentation on how to build them or resolve circular
> incompatibilities. And the unnecessary and unwelcome split among the
> channels "base", powertools", "appstream" and "my uncle's secret ninja
> repo that RHEL originally refused to publish because you shouldn't
> need those to compile things we compile in-house", now called "devel"
> were unwelcome splits.
> 
> And oh, the "we leave out encryption related components for popular
> open source tools that we used to publish in RHEL 7" have eaten my
> development time building up python module tool chains, especially for
> awx, the ansible tower equivalent. I'm pretty unhappy about it.
>