On 2024/10/06 16:52:39 +0000, Klemens Nanni <[email protected]> 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.
