Comment 54 for bug 448095

Since I haven't been looking at this bug for a while, I'll just dump my ideas of what IMO should be done in the postinst (and maybe other) package scripts, before I forget them.

There's a couple of situations that should be handled:

a) installing resolvconf while being in a non-resolvconf state
b) upgrading resolvconf that has it's data in another place than the new resolvconf expects it to be (NOTE: which isn't necessarily /lib/init/rw! It's actual location is defined in /etc/default/resolvconf)

In situation A, the problem is that resolvconf doesn't have the information yet to populate resolv.conf, so it should not be activated until reboot, or at least until networking is restarted. It's of course possible to already set up the right /etc/resolv.conf symlink, but the active /etc/resolv.conf should be copied into resolvconf's symlink target file verbatim, and should not be re-generated by resolvconf (possibly by implicitly disabling updates). This is a problem that already exists with the 'official' resolvconf, so it's not a new problem.

In situation B I think we should copy the 'interfaces' folder from the old location over to the new location, maybe in combination with some validity checks to see if the information there matches the active network interfaces. The place of the old location might be deduced from the /etc/resolv.conf symlink, and/or from the old default location under /var. Also maybe cleanup the files at the old location.

If I missed any other situations that might give rise to problems, please add them to this bugreport!