touch-packages team mailing list archive

[Thomas Hood <1453185@xxxxxxxxxxxxxxxxxx>]

Continuing with my investigation of how a default symlink field got
created for resolvconf on my machine... (What I am calling a 'default
symlink field' is the set of symlinks /etc/rc[1-5].d/S??resolvconf ->
../init.d/resolvconf as would be created by "update-rc.d resolvconf
defaults" with update-rc.d from older sysv-rc packages.)

Debian
------
Support for "start" and "stop" commands to update-rc.d was dropped in sysvinit 2.88dsf-42 which was released 13 July 2013. This is what led to Debian bug report #718232 which led to the change to resolvconf mentioned above, which saw the light of day in resolvconf 1.75 released in May 2014. Unfortunately, this resolvconf release didn't constrain the version of sysv-rc with which it could be installed. It should have declared something like Breaks: sysv-rc (<< 2.88dsf-42). This is a bug in Debian resolvconf. Jessie includes sysv-rc 2.88dsf-59 but the previous release Wheezy contains only 2.88dsf-41, so on upgrade from Wheezy to Jessie it is possible that resolvconf upgrades first and its postinst executes update-rc.d from the previous release. I imagine that this could create a default symlink field for resolvconf.

Ubuntu
------
The start-and-stopless version of sysvinit appeared in Ubuntu only in 15.04. But Ubuntu resolvconf postinst was doing "update-rc.d resolvconf defaults" even earlier than May 2014 as evidenced by insserv warnings in my logs. Checking old versions of Ubuntu resolvconf I see that the following versions did "update-rc.d resolvconf defaults".

* 1.77ubuntu1   YES
* 1.76ubuntu1 in Vivid 15.04   YES
* 1.69ubuntu4 in Utopic 14.10   YES
* 1.69ubuntu1.1 in Trusty-updates   YES
* 1.69ubuntu1 in Trusty 14.04    YES
* 1.63ubuntu16 in Precise-updates   NO
* 1.63ubuntu11 in Precise   NO
* 1.45ubuntu1 in Lucid   NO

I think that this means that a LOT of Ubuntu machines have default
symlink fields for resolvconf. Which is wrong and bad unless these
symlinks can have no effect, in which case it's merely ugly. Resolvconf
has long had an Upstart job configuration file and now has a systemd
unit file, so I hope that this means that the bogus symlinks could never
have had any effect.

What do you think, Martin?  Was there in Trusty or later an option to
run Ubuntu with sysvinit instead of Upstart, or do the rc symlinks have
side effects even when Upstart is used?

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to resolvconf in Ubuntu.
https://bugs.launchpad.net/bugs/1453185

Title:
  resolvconf: updates are not enabled right after installation

Status in resolvconf package in Ubuntu:
  Fix Released

Bug description:
  Previously, updates were enabled in postinst script, but this enablement was removed in a favour of upstart service (https://bugs.launchpad.net/ubuntu/+source/resolvconf/+bug/931335).
  This worked fine till the switch to systemd - no postinst action to activate resolvconf.service right after installation, one needs to reboot node in order to get updates enabled.

  Description:	Ubuntu 15.04
  Release:	15.04

  resolvconf      1.76ubuntu1

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/resolvconf/+bug/1453185/+subscriptions