On Jun 7, 2017, at 2:24 PM, Always Learning centos@u68.u22.net wrote:
What is the advantage of patches over a virgin version that can be subsequently patched ?
Doing the change as a patch to the upstream RPM means that, most of the time, you can just apply your patch again whenever the upstream RPM changes. If the patch applies cleanly, chances are that your port update is done, right there.
If you fork the package base entirely, you have to backport each change from upstream yourself, which is a much bigger burden. Chances are good that you’ll end up forking the whole OS that way, rather than creating a variant spin of it.
The fork-the-whole-thing model would make sense if you’re starting from C6, since it’s on the downhill side of the patch rate curve now, so that there will be little backporting necessary. And soon, a maintainer of a C6 fork would be on his own anyway, when the upstream patches dry up.
Whereas if you start with C7, you’d like to have the benefit of the upstream changes while you do the smallest amount of work you can while achieving your end of ridding C7 of systemd. The project is likely to take years to complete — after all, it took many years for systemd to get to where it is now — so there’s a good chance you could complete the project before you’re left with an EOL’d C7 base package set.
If you look inside many RPMs, they are composed of the untouched upstream source tarball plus a series of patches. One RPM I looked into recently had something like 30 separate patches applied to it, some from Fedora, some from Red Hat, Inc, and potentially (though not in this specific case) some from the CentOS project. This is the normal way of doing these things.