Comment by jlgaddis | Hacker News Reader

Comment by jlgaddis | Hacker News Reader

Parent Full thread

No kidding, right!?

I mean, if you think about it, all that's really needed is for a "s/CentOS/Rocky/g" over all of the repositories. Then, the other 99% of the project is just waiting for the packages to rebuild and get sync'd on all of the mirrors that they could just will into existence with their minds.

Really, though, let's be honest here: If they weren't spending so much time writing up press releases and commenting on issues on GitHub, they probably could've already basically been done, the new package repositories could've been published and mirrored, and half of the CentOS 8 boxes out there could've already been migrated over.

<sigh>

--

EDIT: To be clear, I am not serious. I thought the question I was replying to was completely f##king absurd but chose to respond with sarcasm (it seemed less likely to result in a warning from @dang than my initial reply).

While I enjoyed your sarcasm it doesn't help answer the question. CentOS did't do their own backporting of fixes, nor development. They take SRPMs from RHEL and do "s/RHEL/CentOS/" on them and then build the SRPMS into RPMs which get published.

Not saying all of the above is trivial but I'd think the code to do it literally exists and is itself open source.

But seriously, can somebody ELI5 this project. If Centos is just 1:1 RHEL with removed branding then what new bugs will show up in Centos that are result of that rebranding and will not be fixed by RHEL devs? Is there a code in RHEL that is also copy writed which had to replaced and maintained by Centos devs? What am I missing?

I'm not fully versed on all the things that would be needed, but at the bare minimum it would seem like you would need a bunch of automated processes for just the building - Import src packages, making sure that you copy in changes/patches when RHEL does. - Replace the RH trademarks in every package - Build every package and run verification tests for each arch - Build ISOs

You would also need I said if infrastructure servers that can scale to a large number of users for Yum/RPMs, etc.

Then you also need a set of servers for issue tracking and a way to break it out per package.

I wouldn't imagine that it is anything which can't be done, it just seems like there's a lot of little pieces that you would need to set up, and infrastructure you need to run.

Reply on news.ycombinator.com