On Fri, Jan 22, 2021 at 9:22 AM Lamar Owen <lowen at pari.edu> wrote: > > 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. To be clear, customers need to be deterred from inadvertently walking themselves into unsupported situations and then being surprised about it later. That's the part that wasn't successful about Optional. Availability and installation of those packages is perfectly fine as long as people are aware of the implications. Every customer and user has different risk tolerances and development models. So it's not "don't install these packages", it's "understand what it means to rely on these 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!). The missing subpackages are indeed painful and we're aware of it. > 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? That's a good question and it's not an easy one to answer. Increasingly upstreams are using distribution models that eschew the traditional distribution model of yesterday. Matthew Miller, the Fedora Project Leader, gave a great talk related to this a while ago. He pointed out in the early days, getting your package into a Linux distribution was the primary way to make it popular and meet your users. Over time that's become less and less of the case, with competing package formats, pace of distributions, and version choice (or proliferation) all leading to developers wanting more control over the software stack. CPAN, the nodejs ecosystem, pip, rust crates, etc are all examples of upstream approaches to accommodate this. When you extend those factors to a long lifecycle enterprise focused environment, things become even more challenging. Increasingly we're trying to focus the operating system on meeting the fundamental needs while providing choice in some of these areas. However we can't provide every possible version, and often developers don't want us to anyway. It's been a really hard problem to think about and try to address and we're always trying to evolve there. josh