On 12/17/2020 9:29 AM, Lamar Owen wrote:
On 12/13/20 3:25 PM, Dave Stevens wrote:
On Sun, 13 Dec 2020 21:05:42 +0100 Rainer Duffner
<rainer@xxxxxxxxxxxxxxx> wrote:
It’s also not often the case that you can split this kind of work
into a thousand work-packages and have everybody just work 1/2 hour
a day on it.
not like Debian for instance
No, not at all like Debian. Debian doesn't have to try to match the
unattainable goal of 100% binary compatibility with an upstream
source. I've seen a small part of this first-hand, and deducing the
build order to gain binary compatibility is the one thing that can
single-thread the build process quicker than anything else. RHEL
doesn't even have the same need; an RHEL rebuild that didn't have the
goal to be bug-compatible near the 100% level doesn't, either, and can
be built by a lot of people.
Try it yourself: go back to CentOS 5.5 and attempt to rebuild the
released sources for 5.6 and get a binary compatible build. I've done
it myself for IA64; it was a pain.
All of the upstream distributions, Debian, Fedora, etc, have a lot of
latitude that CentOS never has enjoyed.
Given that rebuilds /had/ been taking longer and longer lengths of time,
it was clearly hop(e)xpected that bringing CentOS into the RedHat fold
in an official partnership in 2014 would allow for direct access to the
RHEL engineers and a path toward making the CentOS Project's rebuilds
easier. Indeed, although it's been six years, moving to integrating
EL/ELN/CS and RHEL in some way in the pipeline is precisely what had
been desired... BUT, defining the problem out of existence while also
defining "CentOS Linux" out of existence helps absolutely no one (on the
outside, at least). And cutting the support period for 8 in half is so
disruptive as to outweigh the progress in other areas.
-jc
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
https://lists.centos.org/mailman/listinfo/centos
