@the-maldridge
I'm curious as to what "don't really like this package" means in a more specific, technical sense. Is it my job packaging it, the implementation, or just the kludgey teredo protocol?
It's primarily the large patch included, the <imho> complex run script, and the general complexity of the template. If the patch weren't there I'd be happier, but that is still a complex run script.
The readme should also go, its not within our policy to have such readmes.
@the-maldridge
I got rid of the README.Void file, although I must say that a policy of *not* documenting things rubs me the wrong way. Seems like there aren't really any downsides to including a file describing the choices made and how to integrate the service into a Void system.
I simplified the run script. I had made it complex as a feature: it tried to do things the "right" way, without requiring user configuration beyond editing the miredo.conf file. Since using tunnels of any sort is intrinsically messy, this was complex. Perhaps this approach was misguided.
The complexity of the template involves several things. The need to adapt to the void layout and to use runit instead of systemd is pretty much unavoidable.
The use of libjudy, and its inability to cross-compile is rather messy. And libjudy appears to be just an optimisation, not a requirement. I stuck with it because everyone else seems to use it, and I have no idea at what point it the optimisation becomes a good idea, or even if the non-libjudy implementation works. I can say that I have seen a surprisingly large number of teredo connections hitting IPv6 enabled services, which is why I like to run a teredo relay on my gateways. So optimisation is not necessarily useless here. I could look into the behaviour without libjudy, but would prefer to avoid the work.