Issue with the way conntrack is disabled
ArchWiki recommends setting an outgoing port range.
outgoing_ports if set to something other than (0, 0) is a range of ports used to bind outgoing sockets to. This may be useful for users whose router allows them to assign QoS classes to traffic based on its local port. It is a range instead of a single port because of the problems with failing to reconnect to peers if a previous socket to that peer and port is in TIME_WAIT state.
WARNING setting outgoing ports will limit the ability to keep multiple connections to the same client, even for different torrents. It is not recommended to change this setting. Its main purpose is to use as an escape hatch for cheap routers with QoS capability but can only classify flows based on port numbers.
This can likely be bypassed by disabling conntrack on all unprivileged or ephemeral ports and not restricting the outgoing port range in the settings. As things are documented right now, it stands to reason that things could get worse this way.
Workaround for issues with connection tracking
This is an issue. Setting the outgoing ports can introduce new problems. So naturally, one would try to disable it for the entire outgoing port range if only deluge is intended to make outgoing connections. This introduces issues with DNS resolution. A work-around is to enter --source IP_DNS_SERVER rules that ACCEPT the raw packages before NOTRACK is joined. --SAKUJ0 (talk) 19:21, 30 September 2015 (UTC)
Split package in the AUR
Regarding your edit: FS#16772 been rejected. I also know that most maintainers will not want the added burden of building the split package as I have since upstream does not supply make targets yet. My AUR package both supplies less files (no *.pyc or *.pyo) and it is a split package allowing flexibility in installed size and in respective deps. I would therefore argue it is not identical to . Graysky (talk) 21:01, 28 November 2016 (UTC)