New comment by zmudc on void-packages repository

https://github.com/void-linux/void-packages/issues/45522#issuecomment-1683007957

Comment:
As @ahesford says here:

https://github.com/void-linux/void-packages/pull/45307#issuecomment-1682870675

Void will not accept the patch to not daemonize vncsession until upstream accepts it.

Therefore, this issue cannot be fixed without help from upstream, and upstream seems not interested in supporting systems like Void that do not use a Type=forking systemd service. For example, see the comment of an upstream developer here about non-systemd systems:

https://github.com/TigerVNC/tigervnc/issues/1443#issuecomment-1064207695

and this comment of the same upstream developer which places the burden on downstreams like Void to adjust the upstream TigerVNC server to work with non-systemd service managers that downstreams might use:

https://github.com/TigerVNC/tigervnc/issues/1443#issuecomment-1067863076

This makes it difficult to use the TigerVNC server on Void in a manner that upstream intends, because AFAICT Void does not currently have a way to port a Type=forking systemd service to runit, and upstream is not willing to do the work of supporting non-systemd system managers like runit on Void.

So what is the solution for the problem of porting an upstream component like vncsession that forks and is therefore not compatible with Void's runit system? Do we just say we cannot use that upstream component in the official Void packages?