On Thu, May 6, 2021 at 5:10 PM ~Stack~ <[log in to unmask]> wrote:
>
> On 5/6/21 3:21 PM, Yasha Karant wrote:
> > Excerpt from a previous post on this matter:
> >
> > On Thu, 2021-05-06 at 02:43 -0400, Nico Kadel-Garcia wrote:
> > The misfeatures you've groused about are not due to AlmaLinux, they're
> > straight RHEL problems. Let's assign blame and credit where they are
> > due.
> > End excerpt.
> >
> > Presumably, Rocky Linux (IBM RHEL "clone") does have the same
> > "misfeatures"?  Would one of the after-EL repos (ElRepo et al.) be
> > willing to produce an alternative set of RPMs to address the
> > "misfeatures"?  Would Alma or Rocky or ... ?  No point in mentioning
> > Fermilab/CERN -- SL8 will never exist.
>
> Since Rocky is aiming for exact 1:1 compatibility then I would say that
> there won't be much deviation there.

Yeah. One big issue right now is anaconda, the installer suite, which
is vulnerable to feature creep at the cost of useful options. It's no
longer possible in the GUI to pick and choose individual packages or
bundles of software, and the lack of a default mirror for network
based installation is just plain stupid. Unless you're a weasel like
me, you're unlikely to deduce that a working URL for CentOS
installation these days isis:

      https://urldefense.proofpoint.com/v2/url?u=https-3A__mirrors.edge.kernel.org_centos_8.3.2011_BaseOS_x86-5F64_os_&d=DwIBaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A&m=JR5cD1Xb1tqRHGWZdGLlAWREFWF4CKOWq0L5ZoV2VHg&s=2E6MIenexPd9zIKcsox02VQrb3WPpzfLEfwFh7eXqo8&e= 

Notice the "BasOS", then architecture, then "os", instead of the older:

     https://urldefense.proofpoint.com/v2/url?u=https-3A__mirrors.edge.kernel.org_centos_7.9.2009_os_x86-5F64_&d=DwIBaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A&m=JR5cD1Xb1tqRHGWZdGLlAWREFWF4CKOWq0L5ZoV2VHg&s=282CfpGbJLtAhSwtXeQ9PYxy5liO5Gh5rZcmWbIMncc&e= 

Notice that "BaseOS" is now considered more important than the
architecture or the OS, even though the channel only really makes
sense as part of the "os". Every RHEL 8 fork is going to have to deal
with this unwelcome segregation of paritally overlapping channels, all
of which are needed for a pretty basic server grade OS installation.

I think the theory was to split the load at Red Hat, to reduce the
metadata burden of having a single channel and reduce the load on
their servers. It's not helpful.

Anaconda has other issues: the difficulty of scripting and making its
behavior consistent isn't burdensome if you're, well, *me* and you can
handwrite ks.cfg files. But the kickstart GUI is pretty bad, and has
no options to include muliple '%pre' or '%post' scripts, it erases
multiple such scripts that may be read from a reference ks.cfg.