net-misc/netifrc-0.7.3-r1 adds a dhcp use flag, which is fine but I use sys-apps/busybox for dhcp. I tried an emerge with USE=-dhcp, net-misc/netifrc-0.7.3-r1 works perfectly fine with sys-apps/busybox-1.34.1 (I restarted my wlan0 to be sure).
From /usr/share/doc/netifrc-0.7.3-r1/net.example.bz2 :
# DHCP can be provided by dhclient, dhcpcd, pump or udhcpc.
# dhclient: emerge net-misc/dhcp
# dhcpcd: emerge net-misc/dhcpcd
# pump: emerge net-misc/pump
# udhcpc: emerge sys-apps/busybox
busybox was excluded on purpose; it's a really limited implementation intended for minimal systems. Most users will be happier with dhcpcd or dhclient.
I know it's not perfect but my thought was that advanced users who really want busybox udhcpc can just set -dhcp and go on how they have before.
Setting -dhcp won't have any ill effect for you if you are already bringing your own dhcp client (whether it be busybox, or pump which is no longer in ::gentoo, or some hand-built thing).
* Messages for package net-misc/dhcp-4.4.3-r1:
* The client and relay functionality will be removed in the next release!
* Upstream have decided to discontinue this functionality.
But dhclient was kept, somehow. Most users will be happier when it finally breaks, I suppose ?
Fine for me, I will leave -dhcp for netifrc then.
I've experimented with the combination of netifrc and udhcpc in the past and found it to be unreliable. By unreliable, I mean that, while it would work fine on some hosts, on others it would inexplicably fail to obtain a lease within its default timeout period. Further, in those situations where udhcpc would fail, using either of dhcpcd or dhclient would rectify the issue.
Therefore, I would emphasise what Mike said; I don't think that it should be endorsed as a client to be used by netifrc. On the other hand, the new ebuild will result in the client being switched under the following conditions:
- neither dhcpcd nor dhclient were previously installed, while busybox was
- the user relied on the udhcpc module being implicitly selected, rather than having selected it with "modules" or "modules_interfacename"
- the user didn't inspect the ebuild so as to realise the nature of the change and set "-dhcp" in advance, resulting in another client being installed that is preferred by netifrc
Assuming that net-misc/busybox is not going to be added to the ebuild, I'd suggest adding a brief post-install message for now, so that those invested in udhcpc aren't caught off-guard. Ben, what do you think?
As an aside, net-misc/pump no longer exists so there's a case to be made for removing support from netifrc.
(In reply to Gabriel Linder from comment #3)
> * Messages for package net-misc/dhcp-4.4.3-r1:
> * The client and relay functionality will be removed in the next release!
> * Upstream have decided to discontinue this functionality.
> But dhclient was kept, somehow. Most users will be happier when it finally
> breaks, I suppose ?
Given the change to the ebuild, I think it's the case that dhcp functionality should only break outright in the case that USE="-dhcp" is set and the user explicitly selected the dhclient module in /etc/conf.d/net. Still, that's interesting. Perhaps it would merit a news item when the time comes.