#DEBHELPER# token is in the wrong place, and other resolvconf postinst nits

[Thomas Hood]

Background: In the Debian version of the resolvconf package, dh_installinit is run with the "--no-start" option and actions equivalent to "invoke-rc.d resolvconf start" are performed later in the postinst after necessary preparation has been done.

The problem: While converting from sysvinit to Upstart, "--no-start" was replaced with "-r" but there are still some loose ends, some minor, but I take this opportunity to mention them as well.

* First, the "#DEBHELPER#" token is in the wrong place. It should be placed after the postinst code that linkifies and initializes the database. The reason is that dh_installinit inserts "invoke-rc.d resolvconf start" at the position of the token. (1) If the "invoke-rc.d resolvconf start" happens before initialization of the database then the initial contents of resolv.conf are out of date. (2) If the "invoke-rc.d resolvconf start" happens before linkification and an update script returns an error condition then linkification does not happen. This may be one of the reasons for the malfunctions reported in bug #1000244.

A good place to put the token is right at the end of the file, just before the "exit 0" line.

This was supposedly fixed at one point as indicated by the following changelog entry

    - Move the #DEBHELPER# token in debian/postinst to after the resolv.conf
      symlink is set, [...]

but the current version (1.67ubuntu2) has the "#DEBHELPER#" token back up at the top of the file.

* Second, the comment in the postinst still says that "--no-start" is used

     # We use dh_installinit with --no-start

whereas this is not true in the Ubuntu version. Please remove this line.

* Third, this comment

                                # Even though we create this dir in the preinst,
                        # don't assume that it's still here; a reboot
                        # after unpack may have left us with no upstart
                        # job in place and /run cleaned out.
                        mkdir -p /run/resolvconf/interface

has irregular indentation and duplicates the comment that precedes the if-then block. Simplest thing is to remove the comment (but not the mkdir line!).

* Fourth, this comment

        # FHS violation; get rid of it, we use /run directly now.

incorrectly (IMHO) states that the use of a symbolic link /etc/resolvconf/run -> (some-tmpfs)/resolvconf in the Debian version of the package is a FHS violation. It is not. The run-time state directory of Debian resolvconf is no more in /etc/ than the vi program is in /etc/ just because

    $ ls -l /usr/bin/vi
    lrwxrwxrwx 1 root root 20 Jun 13 09:55 /usr/bin/vi -> /etc/alternatives/vi

In Debian, /etc/resolvconf/run has only ever been a symbolic link to some tmpfs. It is a configurable symbolic link.

So please replace the comment with something less controversial, such as the following.

    # We use /run directly now.

[Steve Langasek (vorlon)]

Stéphane, looks like the #DEBHELPER# issue may have been a mismerge into quantal; assigning to you.

[Steve Langasek (vorlon)]

On Mon, Dec 03, 2012 at 10:56:57AM -0000, Thomas Hood wrote:
> * Fourth, this comment

> # FHS violation; get rid of it, we use /run directly now.

> incorrectly (IMHO) states that the use of a symbolic link
> /etc/resolvconf/run -> (some-tmpfs)/resolvconf in the Debian version of
> the package is a FHS violation. It is not.

The FHS requires that OS software use only paths conformant with the FHS
when *accessing* files, not just that the files be ultimately located in
FHS-compliant directories. So this *is* an FHS violation.

[Launchpad Janitor (janitor)]

This bug was fixed in the package resolvconf - 1.69ubuntu1

---------------
resolvconf (1.69ubuntu1) raring; urgency=low

  * Merge from Debian. Remaining changes: (LP: #1085756)
    - Make /etc/resolv.conf a relative symlink so that it works when
      setting up chroots.
    - Instead of throwing an error that aborts the upgrade when
      /etc/resolv.conf is immutable, pop a debconf error message to let the
      user know what's happening, then clear the immutable flag and continue
      with the installation. LP: #989585.
    - debian/config, debian/templates, debian/postinst: if we don't know that
      /etc/resolv.conf was being dynamically managed before install (in at
      least some cases), link the original contents of /etc/resolv.conf to
      /etc/resolvconf/resolv.conf.d/tail so that any statically configured
      nameservers aren't lost. LP: #923685.
    - Use an upstart job instead of sysvinit script.
    - Pre-Depend on the /run-providing version of initscripts instead of
      depending, so that the preinst does the right thing when creating
      /run/resolvconf/interfaces instead of getting clobbered later by a bind
      mount on initscripts upgrade. LP: #922491.
    - Completely drop the standard_run_subdirs_created helper function from
      debian/postinst, since it serves no purpose here.
    - postinst: Set resolvconf/linkify-resolvconf to false after initial
      conversion, ensuring upgrades won't convert /etc/resolv.conf to
      a symlink if the user manually converted it back to plain text.
      (LP: #922677)
    - Move the #DEBHELPER# token in debian/postinst to after the resolv.conf
      symlink is set, so the init script can actually start (since it expects
      /etc/resolv.conf to be a symlink).
    - Eliminate all references to /etc/resolvconf/run. This should all be done
      directly in /run, there is no reason to support making any of this
      configurable with a symlink since we already have a versioned dependency
      on the version of initscripts that introduces the /run transition.
    - Also remove debian/triggers to avoid needlessly calling resolvconf's
      postinst. (LP: #931335)
  * Fix previous mis-merge of debian/postinst as well as the few other comments
    from the bug report. (LP: #1085862)

resolvconf (1.69) unstable; urgency=low

  * [276fc24] Bump Standards-Version; no changes required
  * [6982da6] README: Name packages that clobber /etc/resolv.conf
  * [4cb082a] README: Update
  * [044e9a3] ip-up.d/000resolvconf: Do nothing if USEPEERDNS not set
  * [d988a9e] if-up.d/000resolvconf: Silently (for now) accept option
    name 'dns-nameserver' as a synonym for 'dns-nameservers' in
    anticipation of support in ifupdown (no sooner than wheezy+1) for
    duplicate options in a stanza, after which it will make sense to
    specify multiple nameserver addresses on equally many
    "dns-nameserver" lines
  * [e0db2cb] Deal with obsolete conf files (Closes: #687507, #681623)
 -- Stephane Graber <email address hidden> Fri, 18 Jan 2013 11:52:10 -0500

[Thomas Hood (jdthood)]

Steve, you wrote:
> The FHS requires that OS software use only paths conformant with the FHS
> when *accessing* files, not just that the files be ultimately located in
> FHS-compliant directories. So this *is* an FHS violation.

This is an interesting argument which I take all the more seriously because it comes from such a knowledgeable developer.

I am surprised by the argument because in the ten years that resolvconf has existed, no one has confronted me with that particular argument before.

I was involved in reviewing the FHS some years ago and I did not form the impression at that time that the FHS forbade the use of (static) symbolic links pointing to non-etc entities. If it did forbid such use of /etc then the whole Debian alternatives mechanism would be in violation of the FHS. And resolvconf itself would be fundamentally in violation since /etc/resolv.conf is a symbolic link to a non-static file outside of /etc. Ditto for serveral analogous uses of symbolic links in /etc.

To see if I have overlooked something, and also acknowledging the possibility that the text may have been revised since I last read it, I have just consulted the FHS again (still at release 2.3, I see) and I still find nothing in it which I interpret as requiring what you say it requires. Which part of the FHS do you base your argument on?

Looking again, I search on the word "access" and I find nothing like what you attribute to the FHS.

Even if the text of the FHS did rule out the use of (static) symbolic links in /etc to non-static targets, the appropriate response would be to fix the text of the FHS. This wouldn't be the first time that the FHS had unintended implications. The FHS is not very well written. The purpose of the FHS is to describe what is common to all operating systems conforming to the standard, not to impose arbitrary pointless limitations on how particular operating systems are configured.

Finally, the reason I carry on this discussion is that I care about standards and want resolvconf to be FHS-compliant. If Debian resolvconf really is FHS-noncompliant then I will fix Debian resolvconf (or the FHS, as appropriate). If Debian resolvconf is FHS compliant, however, then I would prefer it if the Ubuntu variant didn't claim otherwise.

[Thomas Hood (jdthood)]

I want to add: Stéphane, thanks for syncing resolvconf from Debian and for fixing the other issues in #1085862.

P.S. The issue I wrote about earlier isn't whether or not /etc/resolvconf/run is *obsolete*. Since the introduction of /run it *is* obsolete. And I applaud you guys for eliminating its use from the Ubuntu version of the package.

[Thomas Hood (jdthood)]

Just to note that nowadays, e.g., in 1.76ubuntu1, Ubuntu also does `dh_installinit --no-start`.