redis in epel is still the older 2.4.x when 2.6 is the current stable version. Even so, it's a very out of date 2.4.x.
Hello Silas, Is there any possibility of getting an update to 2.6.x in EPEL 6? We are running into some issues with the 2.4.10 package in EPEL 6 now that we believe are solved in 2.6.
I'd also like to see this updated
Anyway we can see this get updated? I'd be willing to help.
(In reply to awiddersheim from comment #3) > Anyway we can see this get updated? I'd be willing to help. Fedora has received the latest update. For EPEL package I'm sorry we can't bump the version as it will cause problem. Migrating from 2.4 to 2.6 ========================= Redis 2.4 is mostly a strict subset of 2.6. However there are a few things that you should be aware of: * You can't use .rdb and AOF files generated with 2.6 into a 2.4 instance. * 2.6 slaves can be attached to 2.4 masters, but not the contrary, and only for the time needed to perform the version upgrade. There are also a few API differences, that are unlikely to cause problems, but it is better to keep them in mind: * SORT now will refuse to sort in numerical mode elements that can't be parsed as numbers. * EXPIREs now all have millisecond resolution (but this is very unlikely to break code that was not conceived exploting the previous resolution error in some way.) * INFO output is a bit different now, and contains empty lines and comments starting with '#'. All the major clients should be already fixed to work with the new INFO format. * Slaves are only read-only by default (but you can change this easily setting the "slave-read-only" configuration option to "no" editing your redis.conf or using CONFIG SET. The following INFO fields were renamed for consistency: changes_since_last_save -> rdb_changes_since_last_save bgsave_in_progress -> rdb_bgsave_in_progress last_save_time -> rdb_last_save_time last_bgsave_status -> rdb_last_bgsave_status bgrewriteaof_in_progress -> aof_rewrite_in_progress bgrewriteaof_scheduled -> aof_rewrite_scheduled The following redis.conf and CONFIG GET / SET parameters changed: * hash-max-zipmap-entries, now replaced by hash-max-ziplist-entries * hash-max-zipmap-value, now replaced by hash-max-ziplist-value * glueoutputbuf option was now completely removed (was deprecated) -------------------------------------------------------------------------------- As you can see many changed.
I will consult with some guys and to see if I have chance to update with RHEL major update.
Any progress on this? EPEL is currently 2 major revisions behind
I think redis can't be upgraded in the repo, instead SCL is recommended. I haven't come up any plan with other maintainers.
Could you explain why redis cannot be upgraded in the repo? I think that any backwards compatibility issues that exist are best solved by clients of the EPEL repo using exclusions to prevent upgrades to redis. The EPEL7 repo contains redis-2.8.14 where the EPEL6 repo contains redis-2.4.10. This is a rather large anomaly which needs to be resolved somehow.
(In reply to Duncan Innes from comment #8) > Could you explain why redis cannot be upgraded in the repo? > > I think that any backwards compatibility issues that exist are best solved > by clients of the EPEL repo using exclusions to prevent upgrades to redis. > > The EPEL7 repo contains redis-2.8.14 where the EPEL6 repo contains > redis-2.4.10. This is a rather large anomaly which needs to be resolved > somehow. http://fedoraproject.org/wiki/EPEL_Updates_Policy
I'm not sure where in the EPEL updates policy it forbids updating an existing package. I suspect your concern around updating may be the following statement? > Major updates with changes to user experence are to be avoided. A maintainer isn't forbidden from updating, but caution should be taken. While an official policy for major release updates in EPEL hasn't yet been documented, I've confirmed with #epel that it is possible. My understanding of the options ... 1) Package redis2.8 as a new EL6 package that is ... a) co-installable with redis b) or "%conflicts redis < 2.8" 2) Update to the latest redis-2.8 on EL6 a) Tell epel-steering-committee you need to break stuff. b) Announce to epel mailing lists that you are going to make a big break. c) Package up the big break and put it in epel-testing. d) Get karma and push to stable. e) Deal with people's breakage as best you can. Given that upstream redis is no longer maintaining updates for either 2.4.x or 2.6.x, it seems sensible to work through option#2. I've been using redis-2.8 on EL6 a private COPR, so I don't think building the package will be problematic. Perhaps just communicating the change (steps 2a and 2b) is more involved.
Please upgrade this repo
Hmm, pardon my brevity here. I understand keeping releases stable/safe, but this seems slightly extremist. To me this looks like an obvious solution: make both the obsolete crufty 2.4.x branch and the newer 3.x branch available, together, with something like %conflicts as James Laska suggests. Hint that 2.4.x is depreciated. Call the new meta something else like "redis-edge" perhaps.... As it stands, 2.4.10 came Mar 31, 2012 and was modified April 4 2012 (3.5 years ago) and hasn't had any EPEL backports even under the advice of Redis "high priority" upgrade recommendations. This means that the current package is more or less abandoned, is not LTS, and because of this, is not considered "viable for production" when compared to the more current versions. Are we including this abandoned package so that enterprise can use obsolete methods? If so, what 5% enterprise really needs this old package when 95% OPS need the new? Would it not make sense instead for the 5% to compile in the older rather than the 95% compile in the newer as it stands now? Or, as suggested, just make both available? 2 packages is not an impossible feat...For example, there are certain multi-version releases such as PHP. You don't push 1 version of PHP right? Why? Because of this EXACT situation: Some people want the newest, some people are locked into legacy and there are "large changes to the new package(s) that may affect user/software experience". Yet, EPEL persists, seemingly violates its own mantra here by making multiple versions available for use which clearly would affect experience in a negative way if wrong version chosen. OPs are perfectly capable of choosing which to use. No OP is confused. No enterprise client is butthurt. Everything works. Can't the jump to modern redis work in the same manner, with the old in a temporary "depreciated meta" state? In the end, Redis is a massively popular package. It's been at 2.4.x in EPEL for too long, in essence creating a turn-off for those who want to quickly spin a modern/cloud/production stack via yum. I understand the goal of RH, but even as LTS/backport style, this redis 2.4.x seems abandoned.
One alternative solution is to use the redis28u or redis30u packages provided by the IUS project [1]. These packages implement many of the ideas suggested so far in this bug. * conflict with redis from EPEL * use an alternate name so that the redis package doesn't get an unexpected major version update * provide the latest upstream supported versions (currently 2.8.24 and 3.0.7) [1]: https://ius.io
redis-3.2.3-1.el7 has been submitted as an update to Fedora EPEL 7. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-23fa04bf1c
redis-3.2.3-1.el7 has been pushed to the Fedora EPEL 7 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-23fa04bf1c
Redis 3.2.3 has been pushed to testing for quite a while. Why is nobody who wanted this update testing this package and leaving feedback at https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-23fa04bf1c. Come on! ;-) Meanwhile a critical security update has been released (Redis 3.2.4) and two other updates with minor and moderate fixes to 3.2.6.
I can't speak for anyone else, but I removed redis from my stack altogether. Directly because of this issue. It was poor form to have blindly pointed at the EPEL Updates Policy (which one could drive a bus through if so wished) as the reason for refusing to budge.
We are also stopped using EPEL for Redis because of this. However, we can still try to help improve the situation. If there is no improvement, I think EPEL should stop offering Redis altogether.
redis-3.2.3-1.el7 has been pushed to the Fedora EPEL 7 stable repository. If problems still persist, please make note of it in this bug report.
Thank you. For those that are on v6.x, there is still Remi (use it in disabled mode, whereas you call --enablerepo=remi only for Redis install/update).
(In reply to Fedora Update System from comment #19) > redis-3.2.3-1.el7 has been pushed to the Fedora EPEL 7 stable repository. If > problems still persist, please make note of it in this bug report. Why did you push a major upgrade under the same package name ? Weren't you supposed to push it under a different name like "redis32" to avoid unwanted upgrades ?
The EPEL Update Policy is documented here: https://fedoraproject.org/wiki/EPEL_Updates_Policy The focus is to "avoid situations that require manual intervention" and to not cause "changes to user experience". Basically, not all upstream projects treat "major" version updates the same. Redis "major" releases are usually highly compatible. 2.8 -> 3.0 https://github.com/antirez/redis/blob/3.0.0/00-RELEASENOTES#L578-L588 3.0 -> 3.2 https://github.com/antirez/redis/blob/3.2.0/00-RELEASENOTES#L984-L996
(In reply to Carl George from comment #22) > The EPEL Update Policy is documented here: > > https://fedoraproject.org/wiki/EPEL_Updates_Policy > > The focus is to "avoid situations that require manual intervention" and to > not cause "changes to user experience". Basically, not all upstream > projects treat "major" version updates the same. Redis "major" releases are > usually highly compatible. > > 2.8 -> 3.0 > https://github.com/antirez/redis/blob/3.0.0/00-RELEASENOTES#L578-L588 > > 3.0 -> 3.2 > https://github.com/antirez/redis/blob/3.2.0/00-RELEASENOTES#L984-L996 Both release notes present non-backward compatible changes, one of them requiring config file change to re-allow network access and another one implying seamless DB upgrade that forbids any rollback. This upgrade actually crashed one of my cluster members due to the default bind change and I had to restore the DB files due to the format upgrade after downgrading. I could just have updated my config file but it's handled by Puppet and I didn't wand to wait for other suprises - No time to test a cluster upgrade. That's not what I call "avoiding situations that require manual intervention". As specified here: https://fedoraproject.org/wiki/EPEL_incompatible_upgrades_policy "For other - non-security - updates, the maintainer MUST NOT push those types of changes to the stable package. Instead, a new package must be made, pass review, and be branched for EPEL only."
Just to be clear, I'm not the maintainer of the EPEL package, just a casual observer. That is unfortunate that the changes affected you like that. If you are looking for major version branch locked redis RPMs, you may consider using https://ius.io, which currently offers redis30u (3.0.x) and redis32u (3.2.x). The incompatible upgrades policy also says this: "However, in certain situations, they are unavoidable. An example of such a situation would be a security update that is difficult/impossible to backport." The update is clearly labeled as "security" in Bodhi. It also spent seven months in testing to give users plenty of time to provide feedback. It was discussed on the epel-devel mailing list as well. https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/message/GYWAP47BVBP6KFCZBMNBWTV2NUYXJ2M2/