On Thu, 6 Feb 2020 16:12:29 +0000 Stuart Henderson wrote: > On 2020/02/06 10:15, Daniel Jakots wrote: > > Hi Theo, > > > > Thanks for working on that! > > > > On Thu, 6 Feb 2020 15:21:23 +0100, Theo Buehler <t...@theobuehler.org> > > wrote: > > > > > First of all, despite the length of this mail, most of the update > > > is straightforward. The diff is an in-place upgrade from 4.0.14 > > > to 5.0.7. > > When the topic came up before, there was some mention of 5.x not > working on some arches, I would like to see this tested on at least > i386, sparc64, aarch64 before it goes in. I can do some tests on i386 > and probably also aarch64 but not sparc64.
It works fine on powerpc, probably one of the less relevant arch to run redis ;) - build log: https://bin.charlenew.xyz/redis.log - test log: https://bin.charlenew.xyz/redis.test.log > > > The release notes (which contain migration instructions at the > > > very end) > > > > > > https://raw.githubusercontent.com/antirez/redis/5.0/00-RELEASENOTES > > > > Since Redis 5.0 is still able to read 4.0 mdb format, I assume for a > > user there is nothing to do. I guess you don't plan to add anything > > to current.html do you? > > > > > look as if there is no risk of losing data due to the migration > > > and looking around on the net I couldn't find any reports of > > > breakage. However, I don't know and can't know for sure. > > > > > > Since we're playing with user data here, it might be more prudent > > > to provide a redis5 port, and to leave it to the users to decide > > > if and when they want to migrate instead of forcing it upon them > > > right when the update goes in (or when they upgrade to 6.7). > > > > AFAIK, redis is (or should be) used as a cache i.e. losing its data > > is a small inconvenience but shouldn't be a problem. > > noooooo, this would be a big problem.... > > > I don't think > > duplicating the port is worth it. > > I do agree with that. > > > > A detail: redis-sentinel is installed as a symlink to > > > redis-server. Ports seem to do this frequently, but I wonder if > > > that should be turned into a hard link as is usually done in base? > > > > What are the pro/cons of using a hard link instead? > > Not sure about pros, but here's a con: you need to check inode numbers > to see for sure where they point (I hate this with the hardlinked > files in base...) >
