Redis is not shipped in EPEL9, because it's in RHEL9. Same with EPEL8
and RHEL8. It is shipped in EPEL7 at version 3.2, presumably because
updating any further would be an incompatible update.
The license change announcement clearly states it will only be for 7.4
and up. The prior branches (6.2.x, 7.0.x, and 7.2.x) are still going
to be maintained as per their security policy [0], and I haven't seen
any indication that these maintenance updates will be anything other
than BSD-3-Clause licensed. The license change commit has only
occurred upstream in their unstable branch (future 7.4), and the 7.2
branch still has the previous license file [1]. This isn't like when
mongodb switched to SSPL for all future versions, including
maintenance/security updates to older branches. Considering these
factors, F39+ can stay on 7.2.x for quite some time. F38 can stay on
7.0.x for the rest of its lifecycle. The only thing we can't do is
update any branch to 7.4.x.
Having keydb obsolete redis in Fedora would not be appropriate in my
opinion, because they are still different software, and a user may
want to have both installed at the same time. Additionally, keydb in
EPEL definitely can't obsolete redis in RHEL. Maybe at some point
we'll go the obsolete route in Fedora with a change proposal and FESCo
approval, but I don't think we're at that point yet.
[0]
https://github.com/redis/redis/security/policy
[1]
https://github.com/redis/redis/blob/7.2/COPYING
On Thu, Mar 21, 2024 at 1:19 PM Scott Williams <vwfoxguru(a)gmail.com> wrote:
Redis-6 is currently shipped in EPEL9, so it seems like a more obvious step-forward wrt
EPEL.
> Honestly trying to replace redis with KeyDB in Fedora would be a step
> backwards and cause headaches so I don't think it's feasible, at least
> until redis v7 features are merged into KeyDB.
Unfortunately, it's still the best option we have. Ideally, redis wouldn't have
done this, but since redis is no longer license compatible, can we really continue to ship
redis-7 in Fedora 40 if we can't patch and maintain it? If KeyDB were to merge and
release a v7 version against the latest BSD code, I agree that it would be a much better
target for Fedora 40. Unfortunately, we're in the awful position of having to choose
between a breaking change for a small amount of users or shipping something that we
can't patch or realistically maintain. If we have some clue that a v7 merge/release
is on the very near horizon for KeyDB, then maybe it makes sense to keep redis and
obsolete it for KeyDB after GA, but it would be preferable, IMO, to have a clean break on
Fedora 40 release if possible, which will also give us a better chance to document it so
the small amount of impacted end-users wrt v7-specific things can prepare for it.
--
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
--
Carl George