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.