On 12/21/20 2:27 PM, Mark Mielke wrote: > We have internal product releases that were last built in 2016, or > 2008, or even 1999, that would take a substantial amount of money to > update to work on latest releases. Today, we can do this by running > older releases. Without these baselines, this becomes "not possible". > It's fundamentally the same problem as the buildroot problem for 100% > perfect reproduction of RPM, but extended beyond RPM to using EL as a > development platform. I'm aware. I work for a vendor that produces binary software for GNU/Linux systems. This is the forward-compatibility problem that I've mentioned previously. Because RHEL isn't necessarily forward compatible with future releases, we may need to build our applications on the oldest release that we support deployments on. That's difficult to do with CentOS Stream. I can think of a couple of possible solutions, but generally, it will be difficult to use CentOS Stream as a build root for an RHEL target. I've been meaning to ask Red Hat if there are programs for vendors that need to build software for RHEL, but I haven't yet. I believe that EPEL has used CenOS as its build root in the past, so I assume this is something that they'll need to solve for. For now, that's one of the exceptions that stands out when I say that I expect CentOS Stream to be better for most purposes. > I can appreciate that you are not aware of this problem Dude. I'm trying to be civil. I'm not really sure if there's a polite way to point out that a whole lot of your arguments seem to conclude and rest on your perception of yourself as the keeper of secret knowledge. You're not, and it's kind of rude.