Hello Stuart, thanks a lot for your comments and sorry for the late reply.
Thanks for the simpler tgz. I only made a change in DESCR to note that qrqscore would need p5-libwww in order to run. Amended tgz attached, and responses to your points are inline below. Is this OK? Enzo On Tue, Dec 30, 2025 at 10:46:48AM +0000, Stuart Henderson wrote: > I would drop the flavour. My understanding is that the OSS emulation in > libossaudio shouldn't be used for new things - the preferred option is > patching to use sndio - sio_open(3) etc - bit otherwise I would use the > existing pulseaudio support. I agree on removing the FLAVORS, if the OSS emulation is considered legacy. The pulseaudio version was the original one I built. Then I realised that the OSS version compiled and ran seamlessly with minimal changes, and no added deps. That's why I tried the version with two FLAVORS. I will see if it is easy to get a native sndio version in the future, but I think it is safer to include only the pulseaudio option for now. > > Various comments, > > - option-specific patches are a pain to deal with, if the flavour was > necessary everything you've done in the patch variants could be handled > by a smaller patch + MAKE_ENV/MAKE_FLAGS instead > OK, point taken. I have now read again about MAKE_ENV/MAKE_FLAGS, and I see what you mean. That makes total sense. > - generally don't patch for strlcpy snprintf etc in ports, if done at all > that should go upstream (but also should check return values etc). > patching to use PATH_MAX+300 for a string holding a path makes no sense. > i'd just drop that patch > OK, I will then make a proper patch and upstream it to the author instead of including it in the port. > - qrqscore needs p5-libwww to run. not sure if it's worth adding a dep. > a note in DESCR might be appropriate but considering the code quality > (besides the string handling, there's unsafe /tmp use, calls to system > for things that woukd be better done from C, etc) I'm not sure I'd > want it going near data fetched from the net > I have added a note in DESCR about that. Well, makes a single request to a page owned by the qrq author. I would probably leave it like it is. > - no need to patch for 'make uninstall', it's never called from ports > point taken. Thanks. > possible simpler tar attached --
qrq_20260105.tgz
Description: application/tar-gz
