From: Omar Polo Subject: Re: update net/toxic to 0.15.1 and net/toxcore to 0.2.19 To: Klemens Nanni Cc: "Kirill A. Korinsky" , ports@openbsd.org Date: Sun, 06 Oct 2024 19:04:13 +0200 On 2024/10/06 16:52:39 +0000, Klemens Nanni 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.