New comment by ahesford on void-packages repository

https://github.com/void-linux/void-packages/issues/34458#issuecomment-993467073

Comment:
1. Do **NOT** remove the udev rule from the package. If it doesn't work as expected, mask it by symlinking `/etc/udev/rules.d/39-usbmuxd.rules` to `/dev/null`. You could also add a `noextract` XBPS rule and reinstall the package, but simply removing the file will break package consistency and your change will be wiped out with the next update anyway.
2. The purpose of the udev rule is to autostart the daemon when a device is attached and kill it on detach. When this works reliably, you should be able to use your device without constantly running the service. In practice, I've seen the daemon hang occasionally when udev should be killing it, so I manage the daemon with runit. (I've never had the issue of competing instances that you see.) your results might differ. Try disabling the runit service and reattaching your phone. It might "just work", Apple style.

The "systemd" TAG line in the udev rule is a signal to systemd that a device unit should be created when this device is added to the system. Since Void does not have systemd, this should have no significance. In the absence of evidence that the systemd tag declaration actually causes a problem in the udev autostart rule, we should assume it takes no meaningful action and avoid carrying a patch for no purpose.

I am an infrequent user of usbmuxd. While it seems udev management of the daemon is sometimes flaky, I do not believe (but really don't know) that the flakiness is a hard dependence on systemd components that Void does not provide. If I am wrong and proper automatic management of the daemon *requires* that systemd manage device units, Void should stop shipping a useless udev rule.