Hi Lamar, > 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. Thanks for speaking this out so clearly and detailed. I can confirm every sentence from my experience and I'm glad I'm not alone :) When you said Node.js I had to smile. My only fear is to think about what's coming next and over next. In the end this is a general problem, not related to Linux alone. But there is also a lot of pain with Linux alone where other UNIX (like) OSes don't behave so bad. Just think back to the ipchains days, and how things have changed over the years. And the net-tools struggle ending up in completely new network tools which make Linux unique in the *X world. Then the lack of in place upgrades for most distributions. The sound system diversity. Not to forget new init systems which turn the whole system and your knowledge about it upside down. Maybe I should also mention filesystems and the underlying infrastructure, where it would be nice to have one or two very good solutions instead of a zoo. The list goes on... Sometimes I feel I really spent too much of my working time just for catching up with the constant changes and I'm wondering why it is like that. That's a question for every Linux contributor but also directly to the big contributors like RedHat. Simon