On 2025/05/12 12:47, Daniel Jakots wrote:
> On Mon, 12 May 2025 10:50:31 +0100, Stuart Henderson
> <stu@spacehopper.org> wrote:
> 
> > On 2025/05/09 21:05, Lydia Sobot wrote:
> > > > out of curiosity, why did you settle for this particular fork?
> > > > it doesn't seem to be super active
> > > > https://codeberg.org/redict/redict/commits/branch/main  
> > > No particular reason except that it seemed decently maintained to me
> > >   
> > > >> I used the UID/GID for Redis for Redict in users.list  
> > > >
> > > > I guess this is fine since I doubt people will want to have both
> > > > at the same time. Not sure if they should conflict.  
> > > Ok, but does that mean that Redict should run under the username
> > > _redis?  
> > 
> > Should use a different uid.
> 
> Why? In case someone wants to run both at the same time?

yeah, the user owns files so if someone is running multiple, having
the possibility to access files from one of the other ports isn't ideal.

> > Personally I'd go with valkey rather than redict, since they kept the
> > original BSD license, and have quite widespread support/active
> > development.
> 
> Indeed, it seems the 'industry' mostly switched to valkey mostly.
> We could offer the three flavors (redis, redict, and valkey), but then,
> if they need to all have their own uid, it's not great as it's a scare
> resource.

it shouldn't be a scarce resource, we badly need dynamic allocation of
uids for the majority of ports where it doesn't matter what the numeric
id is. only a handful of ports need to know the numeric uid at build
time.

> > > > Unless you mean I didn't update the ports tree to the 7.X branch
> > > > (or even the 8.x branch now). But in which case, I haven't heard
> > > > any compelling arguments to do so (which I'd like to have since I
> > > > don't think "newer is better" applies here).  
> > > I am way out of my depth, but why does "newer is better" not apply
> > > here for you? As far as I am concerned, we should try to at least
> > > offer the newest version of ports in the tree by default, even as
> > > just another flavour  
> 
> Sure why not. But nobody seems to care really about it (if you search
> the archive you can find a thread about updating redis but it died
> quickly).

yes. I started on a port, but didn't see any real need to finish it
(especially as 6.x still gets some important fixes). it might not be
too far off being ready, but I wanted to have tests working fully,
and didn't get past "ps: /dev/mem: Permission denied". will dust it
off if anyone's interested...


> > We already have the newest version of the BSD-licensed 6.x branch.
> > The free-of-charge licenses for newer branches are unsuitable for some
> > use cases.
> > 
> > If there is some important reason to have a newer branch then maybe
> > it would be worth having parallel versions in ports, but I'd like
> > to see something specific not just "it's newer".
> 
> Exactly. While I'm reluctant to move the current redis port to either
> 7.x or 8.x (unless, again, there's some good rationale to do so), I've
> no objection with having multiple versions.
> 
> Cheers,
> Daniel