Comment 38 for bug 1176046

Let me try and restate this in detail to make sure I understand it.

Trusty: add a new binary package called isc-dhcp-client-noddns. This will work the same as isc-dhcp-client-ddns in Xenial, but in reverse. It will use the same dpkg-divert mechanism to provide a replacement /sbin/dhclient that does not have the DDNS behaviour. Users must opt in to it by installing this new package, so there should be no change in behaviour to existing Trusty users and thus low regression risk.

Xenial: add a isc-dhcp-client-noddns transitional binary package that deactivates the dpkg-divert and depends on isc-dhcp-client. "Default" users upgrading from Trusty to Xenial are unaffected since they would never have -noddns installed. Trusty users who had opted in to isc-dhcp-client-noddns will transition to the Xenial isc-dhcp-client package that provides no DDNS. Trusty users who are using isc-dhcp-client and want to keep the DDNS support need to install isc-dhcp-client-ddns in Xenial, as before. So no change in behaviour for any use case.

One thing that will need testing is upgrade ordering from Trusty to Xenial with respect to the divert. For example, what if I am using isc-dhcp-client-noddns and ask apt to upgrade me and add isc-dhcp-client-ddns at the same time? Will the overlapping dpkg-diverts behave themselves?

I don't see any problem with this approach, though it does require new binaries in both Trusty and Xenial, which is a little ugly especially for Xenial as there isn't a bug in Xenial currently. I'd appreciate input from another SRU team member on this proposal.

I haven't reviewed your debdiff in detail - let's get general agreement that this is a sensible approach first to avoid any wasted effort. But I did notice:

> +++ isc-dhcp-4.2.4/debian/changelog
> + isc-dhcp-client : dhclient with DDNS functionality enabled

Perhaps add "(no behavioural change from previous version)" or something, to make it clear to existing users seeing the SRU changelog that they don't need to panic? Just noting for the future; no need to do anything now. I think we should get an ack on the approach from ~ubuntu-sru before proceeding further.