On 12/09/2015 02:09 PM, Jamie Nguyen wrote:
On 09/12/15 11:37, Manuel Wolfshant wrote:
As you have already mentioned, all the users need to do is to enable the CR repository . Or wait until CentOS 7.2 will be released, which will happen "soon". And given that the CR repository contains exactly what will become CentOS 7.2 (thus behaving like any regular update), I do not see why wouldn't the NGINX users use it.
I would argue that newcomers to RHEL/CentOS are very likely to have heard of EPEL from numerous guides on the Internet, but are unlikely to have heard of CR (or even know what CR stands for).
1. the issue only affects CentOS users and it will only happen until CentOS 7.2 is released 2. Users and especially newcomers are expected to read the docs. In CentOS 7.2 the CR repo comes preinstalled but disabled.
Also, if a newcomer happens to hear about CR and read the CR page [0], it doesn't exactly fill them with confidence (though I've never actually seen breakage on CR, this is what is advertised):
They are less comprehensively reviewed in the QA validation stage. Will likely have a few more build issues. Please also subscribe to the centos-cr-announce list.
Right. So those with fear in mind should either purchase a RH subscription or wait until CentOS QA is done. Or ask for advice in one of the proper CentOS support channels.
Also, when installing nginx, you get this error message:
--> Finished Dependency Resolution Error: Package: gperftools-libs-2.4-5.el7.x86_64 (epel) Requires: libunwind.so.8()(64bit) You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest
It's not obvious (to the newcomer) from this error message that the solution is to enable CR repository.
It is not obvious at all. But newcomers should read the docs rather that trying copy/pasting random pieces of advice from google
Kind regards, Jamie
None of your arguments changes the fact that the base repository for CentOS 7.1 ships exactly what RHEL shipped in its 7.1 release (modulo the packages which were modified/added/removed by CentOS at the time of release) and by definition this cannot change. The only thing that CentOS could potentially do NOW is to ship the newer libunwind in the 7.1/updates repository but given the potential breakage it might cause and that the release of 7.2 (which includes the new libunwind in the base repo) is "around the corner" I highly doubt that this is a good idea.