On 2024/10/06 16:52:39 +0000, Klemens Nanni <kn@openbsd.org> wrote:
> 06.10.2024 19:40, Omar Polo пишет:
> > Thank you!  I'm generally ok with these patches, provided that we remove
> > net/utox while here.  any oks to do so?
> 
> If it is indeed broken, by the update and/or deprecated upstream:  OK kn.

it is broken by the update, probably already slightly broken, and hasn't
seen a commit upstream in 3 years.

(there is a "fix double free in list when changing settings w/ empty
flist" committed just a couple of days after the last release in 2021)

I guess that if someone wants to work on it, or if upstream starts
working on it again, we can resurrect it from the attic.

> >> --- net/toxic/Makefile	6 May 2024 12:23:55 -0000	1.20
> >> +++ net/toxic/Makefile	5 Oct 2024 13:43:46 -0000
> >> @@ -14,12 +11,13 @@ WANTLIB += alut c config curses curl m o
> >>  WANTLIB += qrencode toxcore util z ${MODPY_WANTLIB}
> >>  
> >>  LIB_DEPENDS =		audio/freealut \
> >> -			net/toxcore \
> >> +			net/toxcore>=0.2.19 \
> > I'm not sold on this one.  We're bumping toxcore major, so the package
> > will register the dependency on toxcore.so.4.0 and (I believe) even a
> > partial upgrade will pull in the new toxcore version.
> > 
> > but even if it didn't, I don't see why we should do this for a lib
> > depends.  I could be convinced if it were a build or run dep.  Do we
> > really want to start tracking the minimum requirements for packages?
> 
> You're probably right about WANTLIB being enough.
> 
> Imho, the version spec just helps tracking this, especially in tightly
> coupled ports.
> 
> Your call.

I was too strong in phrasing that, sorry.  I just meant that in this
case I think it's a bit unnecessary, especially given the major bump.
Also, I'd like to avoid falling in the situation where we go back to
bump the version here after updating net/toxcore.