TLDR: zypper dup will replace redis with valkey, which probably will cause some permission issues. Has anyone tried this already?
Some days ago while doing a zypper dup on my raspberry pi 4, I noticed that redis would be removed. I run Nextcloud, which actively uses redis. I did not like the prospect of this, so I added a lock on redis (zypper al redis) and went on with the update. I’m now at openSUSE Tumbleweed 20240627.
To find out why redis should be removed, I removed the lock again and did another zypper dup. Now the reason for the removal becomes clear:
# zypper dup
Loading repository data...
Reading installed packages...
Warning: You are about to do a distribution upgrade with all enabled repositories. Make sure these repositories are compatible before you continue. See 'man zypper' for more information about this command.
Computing distribution upgrade...
The following 2 NEW packages are going to be installed:
valkey valkey-compat-redis
The following package is going to be REMOVED:
redis
2 new packages to install, 1 to remove.
Overall download size: 0 B. Already cached: 1.5 MiB. After the operation, 30.7 KiB will be freed.
Backend: classic_rpmtrans
Continue? [y/n/v/...? shows all options] (y): n
So, redis is to be replaced by valkey. The reason can be found here.
I would be inclined to leave it locked, but to test whatever applications you use that use redis to ensure they work with properly valkey. valkey is supposed to be a drop-in replacement, but I personally would test my stuff first before changing it out, and also make sure that the data is properly backed up so it can be restored if necessary.
If the package was installed outside the repos (say, for example, you downloaded it from a vendor directly and installed it), you’ll get a warning (unless you suppress them) that a change is being done.
The redis->valkey change is different, because redis changed their licensing to be non-OSI-compliant, so it’s being replaced by valkey.
It’s not clear to me how your question relates to OP’s question here, though…
You want to keep in mind that the longer you hold off transitioning to valkey, the more incompatible it may become. Right now, there’s basically no difference between the two but development time will change that.
Also that bug report seems like more of a migration step the sysadmin should take than an actual bug. Changing ownership of everything from user or group redis to user or group valkey should fix it and that’s not something that the package should do in most cases.
OK, that makes sense. The reason the package change is happening, as I noted, is because of the license change that redis announced a few months ago. valkey is a drop-in replacement that has an OSI-approved open source license. From a packaging perspective, I believe (though I wasn’t involved in the decision to make the change) that the idea is to treat it as a package ‘upgrade’ because (a) it’s a compatible package, and (b) it uses a license compatible with the openSUSE Project’s goal of distributing only “free” (as in “libre”) software.
Well, it might. The valkey developers could well have a goal of maintaining full compatibility with redis while still only licensing under an OSI-approved license.
It’s also possible that they may see opportunities to improve on the feature set and add that in, either as optional or behind-the-scenes optimizations.
Hard to say what the future will hold for that development or for the popularity of redis itself.
This is not my point. I’m not arguing on the license change nor the software being removed from repository.
In my humble opinion, the distribution should not be so intrusive as this, removing user’s installed software, doing service and data migrations that could drives to service outage and possible data loss.
I do appreciate the effort that people put in creating the migration tool , but I would be more conservative. I think it should resides in a specific package that could or not be installed and executed by the administrator when he/she thinks it’s appropriated. But it’s just my opinion.
You’d have to take that up with the maintainers of the package, as they’re the ones who made the decision to handle it this way. In general (and with a few exceptions), the people here are not package maintainers, but fellow users.
I would suggest taking a look at the appropriate mailing lists for any discussions about the decision, or taking it up with the package maintainer directly.
Curious what would happen if I just let zypper go ahead and replace redis with valkey, I now can say: don’t do it!
The conversion clearly does not work, valkey is not started, nor could I get it going manually.
Output of zypper:
# zypper dup
Loading repository data...
Reading installed packages...
Warning: You are about to do a distribution upgrade with all enabled repositories. Make sure these repositories are compatible before you continue. See 'man zypper' for more information about this command.
Computing distribution upgrade...
The following 2 NEW packages are going to be installed:
valkey valkey-compat-redis
The following package is going to be REMOVED:
redis
2 new packages to install, 1 to remove.
Overall download size: 1.5 MiB. Already cached: 0 B. After the operation, 30.6 KiB will be freed.
Backend: classic_rpmtrans
Continue? [y/n/v/...? shows all options] (y):
Retrieving: valkey-7.2.5-3.1.aarch64 (openSUSE-Tumbleweed-Oss) (1/2), 1.5 MiB
Retrieving: valkey-7.2.5-3.1.aarch64.rpm .....................................................................................................[done (3.8 MiB/s)]
Retrieving: valkey-compat-redis-7.2.5-3.1.noarch (openSUSE-Tumbleweed-Oss) (2/2), 8.6 KiB
Retrieving: valkey-compat-redis-7.2.5-3.1.noarch.rpm .....................................................................................................[done]
Checking for file conflicts: .............................................................................................................................[done]
/usr/bin/systemd-sysusers -
Creating group 'valkey' with GID 460.
Creating user 'valkey' (User for valkey key-value store) with UID 460 and GID 460.
See /usr/share/doc/packages/valkey/README.SUSE to continue
(1/2) Installing: valkey-7.2.5-3.1.aarch64 ...............................................................................................................[done]
/etc/redis/*.conf has been copied to /etc/valkey. Manual review of adjusted configs is strongly suggested.
chown: warning: '.' should be ':': 'valkey.'
On-disk redis dumps copied from /var/lib/redis/ to /var/lib/valkey
Removed "/etc/systemd/system/redis.target.wants/redis@default.service".
Removed "/etc/systemd/system/multi-user.target.wants/redis@default.service".
Warning: The unit file, source configuration file or drop-ins of redis.target changed on disk. Run 'systemctl daemon-reload' to reload units.
Failed to stop redis@.service: Unit name redis@.service is missing the instance name.
See system logs and 'systemctl status redis@.service' for details.
Warning: The unit file, source configuration file or drop-ins of redis-sentinel.target changed on disk. Run 'systemctl daemon-reload' to reload units.
Failed to stop redis-sentinel@.service: Unit name redis-sentinel@.service is missing the instance name.
See system logs and 'systemctl status redis-sentinel@.service' for details.
warning: file /var/lib/redis: remove failed: No such file or directory
(2/2) Installing: valkey-compat-redis-7.2.5-3.1.noarch ...................................................................................................[done]
Running post-transaction scripts .........................................................................................................................[done]
The fact that the conversion script contains chown -R valkey. /var/lib/valkey, where the dot should have been a colon (hence the chown warning) did not boost my confidence level in the first place.
Anyhew, I added my experience to the bug entry and used my latest back up as a life line out of this rabbit hole that I’m not willing to go in to right now. If asked to test out things, I of course would be willing to do so.