Comment 6 for bug 1428486

@Steve: so, as the transition is complex, in addition to my own tests of upgrade/removal/install directly the new version, I asked Martin for a review as well. Here is the patch.

I only took care about statd for now. Note that there are some subtilities from that transition is quite complex, especially as we are upgrading under upstart to enable sytemd or that some people are already on systemd and if we switched back to upstart later this cycle…). That's why you don't see me using update-rc.d on the upstart job (I have a fix on update-rc.d waiting on the debian BTS for quite some months to get reviewed, but I'm unsure it worthes it TBH), and the double lines in the conffiles to ease the transition.
This part should be dealt and works well.

However, we are quite unsure about rpc-statd versus rpc-statd-notify. Can you give a look at 27-systemd-enable-with-systemctl-statd.patch?
To mimick what we had, and the comment for nfs-client.target:
"# Note: we don't "Wants=rpc-statd.service" as "mount.nfs" will arrange to
# start that on demand if needed."
I added WantendBy=nfs-client.target in rpc-statd-notify.service.

On the nfs server side, we have rpc-statd which is WantedBy=nfs-server and Wants: rpc-statd-notify

As we both have no clue about statd on NFS, a double checking would be appreciated! That would result to enable statd:
- on the client: systemctl enable rpc-statd-notify (or pulled by rpc-statd if enabled by mount.nfs, so we can maybe remove the -notify dep?)
- on the server: systemctl enable rpc-statd

Does it make sense?