[CentOS-devel] May we get all subpackages in C8S repos?

On 1/21/21 4:02 PM, Josh Boyer wrote:
> On Thu, Jan 21, 2021 at 9:57 AM Alfredo Moralejo Alonso 
> <amoralej at redhat.com> wrote:
>> Putting all "unsupported" content in a separated -unsupported repo 
>> which would be disabled by default could be a suitable solution 
>> (similar to current Devel but automatically populated with unshipped 
>> content on each new build). 
> It's not a bad suggestion, but experience shows that naming or 
> including "unsupported" in a repo or a package name doesn't mean much. 
> If people can install it, they will. Also, we largely did that in RHEL 
> 7. It is called the Optional repo and the content in there is 
> unsupported. Let's just say it was not the deterrent that was 
> originally envisioned and led to a number of problems.
This honestly is one of the issues that has been in the top five reasons 
that I will be transitioning all of the systems I manage, personal and 
business, to something else.

The package selection in RHEL is quite sparse, and is seemingly actively 
designed to make it difficult to impossible to build certain desirable 
enterprise packages, both at the server level and the workstation level. 
Missing buildrequires, missing -devel packages, missing PCI IDs in 
shipped drivers, and now the attitude that users need 'deterred' from 
installing unsupported packages.

Yes, I am fully aware of the cost to Red Hat of customer-installed 
unsupported packages, but I also have experienced the hoops one must 
jump and contort through to get certain needed packages (at least for 
us) built and running. Yes, I know customers will install things and 
then expect Red Hat to support the packages that they installed out of 
band, yes, I know all this. I know the reasoning; I just simply can't do 
things this way any more in my environment, and I was using CentOS 
anyway, so I had no expectation of support.  Free RHEL will make it 
worse, not better, in this regard, since CentOS provided some of the 
packages that are needed to build other things, and free RHEL is the 
same binary distribution as non-free RHEL, meaning constraints and 
restrictions on packages that are allowed in a supported RHEL instance 
affect the free RHEL instances equally.

I have spent hundreds of hours rebuilding packages, from CentOS git when 
it was a case of an omitted subpackage (a seriously annoying thing, 
because then it blocks updates until I have another set rebuilt), from 
Fedora source RPM when possible for packages not in the CentOS git, from 
my own developed RPMs when RPMs are relatively easily supported but 
Fedora SRPMS aren't available, and from simple source tree using the 
upstream package's build regime (snaps, flatpaks, Anaconda3 (the python 
packaging system), PyPI, and other weirdnesses) because the upstream 
project seemingly has a vendetta against OS packages (Certbot, I'm 
looking at you!).

I've documented the process for a few of those, including posting, on 
the CentOS forums, my success building one such difficult package 
several months ago (the package was KiCAD 5.x).  Most of the issues were 
with workstations, but when I began building the Canvas LMS for a server 
here I entered into a whole new world of packaging pain that I didn't 
know existed, this THING called Node.js.  Python and Perl subpackages 
were and are hard enough (I packaged PostgreSQL years ago, and the 
Python and Perl subpackages were the most 'fun'); why does every project 
think they just MUST reinvent the packaging wheel?

Packaging and repackaging have been so central to my needs that one of 
the first things I started reading about when I started looking at the 
alternatives was how to build packages.  It sounded sad enough thinking 
it; re-reading it after typing it - it really sounds sad now that my 
choice of distribution going forward is somewhat predicated upon how 
easy it would be to patch that distribution's package breakage.