Opened 8 years ago

Closed 7 years ago

#1147 closed defect (wontfix)

RPM: Conflict with EPEL package

Reported by: gtirloni@… Owned by:
Priority: minor Milestone:
Component: nginx-package Version: 1.10.x
Keywords: Cc:
uname -a: Linux host 3.10.0-327.36.3.el7.x86_64 #1 SMP Mon Oct 24 16:09:20 UTC 2016
nginx -V: nginx version: nginx/1.10.1
built by gcc 4.8.5 20150623 (Red Hat 4.8.5-4) (GCC)
built with OpenSSL 1.0.1e-fips 11 Feb 2013
TLS SNI support enabled
configure arguments: --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx --modules-path=/usr/lib64/nginx/modules --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --pid-path=/var/run/ --lock-path=/var/run/nginx.lock --http-client-body-temp-path=/var/cache/nginx/client_temp --http-proxy-temp-path=/var/cache/nginx/proxy_temp --http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp --http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp --http-scgi-temp-path=/var/cache/nginx/scgi_temp --user=nginx --group=nginx --with-http_ssl_module --with-http_realip_module --with-http_addition_module --with-http_sub_module --with-http_dav_module --with-http_flv_module --with-http_mp4_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_random_index_module --with-http_secure_link_module --with-http_stub_status_module --with-http_auth_request_module --with-http_xslt_module=dynamic --with-http_image_filter_module=dynamic --with-http_geoip_module=dynamic --with-http_perl_module=dynamic --add-dynamic-module=njs-1c50334fbea6/nginx --with-threads --with-stream --with-stream_ssl_module --with-http_slice_module --with-mail --with-mail_ssl_module --with-file-aio --with-ipv6 --with-http_v2_module --with-cc-opt='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic'


The latest update to EPEL's nginx package is causing nginx's official RPM package to be overwritten:


$ rpm -qip ./nginx-1.10.2-1.el7.ngx.x86_64.rpm
warning: ./nginx-1.10.2-1.el7.ngx.x86_64.rpm: Header V4 RSA/SHA1 Signature, key ID 7bd9bf62: NOKEY
Name : nginx
Epoch : 1
Version : 1.10.2
Release : 1.el7.ngx
Architecture: x86_64
Install Date: (not installed)
Group : System Environment/Daemons
Size : 2255765
License : 2-clause BSD-like license
Signature : RSA/SHA1, Tue 18 Oct 2016 03:26:36 PM BRST, Key ID abf5bd827bd9bf62
Source RPM : nginx-1.10.2-1.el7.ngx.src.rpm
Build Date : Tue 18 Oct 2016 02:37:31 PM BRST
Build Host :


$ rpm -qpi ./nginx-1.10.2-1.el7.x86_64.rpm
Name : nginx
Epoch : 1
Version : 1.10.2
Release : 1.el7
Architecture: x86_64
Install Date: (not installed)
Group : System Environment/Daemons
Size : 1459372
License : BSD
Signature : RSA/SHA256, Fri 04 Nov 2016 08:25:30 AM UTC, Key ID 6a2faea2352c64e5
Source RPM : nginx-1.10.2-1.el7.src.rpm
Build Date : Mon 31 Oct 2016 12:39:41 PM UTC
Build Host :

My suggestion is to make the official RPMs use EPOCH=2 to avoid this.

Unless the EPEL package is not being kept in sync with the official releases. But even then, it's a different delivery method (EPEL breaks the package into subpackages for the modules).

Change History (1)

comment:1 by thresh, 7 years ago

Resolution: wontfix
Status: newclosed

I don't think that changing Epoch will fix the problem here. Any time EPEL raises their own, we're in the same situation - so it's a mouse and a cat game nobody can win.

A proper solution for this specific case is not to mix the repositories; if that's impossible, use yum's priorities mechanism to adjust repos priorities. See for details on how to do that.

Note: See TracTickets for help on using tickets.