In an earlier article on CentOS Linux 7 (1708), I explained the the basic release process and about things like the Continuous Release (CR) repository. I am not going to go into detail about those two topics here, just update you on the process.

The packages that make up what will be our CentOS Linux 7 (1708), minus the distribution installer and the new release files, are now in our CR repository. Package release announcements. The release notes are here for the release.

The CentOS team rolled in a bugfix to iptables to prevent the service from not restarting on any systems that do not use firewalld but have ip6tables and iptables on. We used this patch in the fix. We do not normally do that (normally only fix bugs when the source RPM is released upstream), but in this case we decided to because of the impact of no firewall on a huge number of internet facing machines that use CentOS. The new package versioning (iptables-*1.4.21-18.0.el7*) is such that when a replacement is released by Red Hat for RHEL and after we build it, it will replace our version in this release.

Some things of note about this release

We had a record number of missing build requirements (that is, things required to build the release that are not actually in the distribution to run the released packages). These packages are not part of RHEL proper and each one has to be researched and an appropriate package found (usually from EPEL or the Fedora Archives) to build the packages. In the 1708 release, we had 11 of those source packages to find. In the previous four CentOS release cycles there were a total of 5.

There are a larger number of services that have been rebased to newer versions in this release than in the past. This seems to be a trend by the RHEL engineers to give the releases newer software, especially in the desktop/GUI areas, while still backporting most of the server related packages to maintain ABI/API compatibility. The release notes talk about specific libraries that were rebased. I like rebases, they give us newer stuff and who doesn't like that 🙂 .. but, they also mean newer shared libraries and that makes finding the correct build order for packages even more important. This lead to a larger number of packages requiring rebuilding more than one time during the process because they had older shared library links initially.

Who should not install the CR (and wait for the full release)

The CR repository is not on by default and it is an opt-in process. It usually takes 2-3 weeks after the CR release for the final release (to get the installer working, compile the full tree from older releases and the newer updates, generate install media, cloud images, vagrant boxes, container images, etc.).

Everyone wants to upgrade immediately (me too 🙂 ), but you may need to hold off for some of the following reasons.

If you use lots of third party repositories (EPEL, Nux!, CentOS Plus, etc.) then some of those packages could be outdated and the developers may need to link against newer libraries. Your upgrade might work fine, it might not. The CR is how we make our packages available to these devs, so it make take some amout of time before everything in 3rd party repos (and even CentOS Plus and CentOS Extras) work completely. Special Interest Group content also may need to be rebuilt against the newer shared libraries before they work. I don't track each and every SIG, but I am involved in the Virt SIG and I maintain several of the xen packages there. The xen repository needs a newer libvirt and seabios and then to have the xen packages rebuilt against that (as an example). CR is how we make the new packages available for the Devs to be able to do that.

Each install is unique and should be tested before upgrading. Many of the libraries have compatibility versions in the release an some things will work from the above, others will not. yum should tell you any errors if it can not upgrade.

How to enable CR

You can enable CR with the command: yum-config-manager --enable cr

After that you can upgrade with the command: yum update

Notes:

A change to rdma-core package from a nonarch to an arch version might want to bring in i686 packages due to the way 'obsoletes' work in yum. This is a known upstream issue: bug and is in the release notes .. so if you don't want the extra couple i686 packages do this for the update: yum update rdma-core After that completes, run yum update for the rest of the updated packages. The version of libgpod that was in EPEL before this update set was newer than the one released. If you have that installed, you must first do yum downgrade libgpod , then do yum update

Enjoy!