[Bug 1085862] Re: #DEBHELPER# token is in the wrong place, and other resolvconf postinst nits

[Thomas Hood]

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.

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to resolvconf in Ubuntu.
https://bugs.launchpad.net/bugs/1085862

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

Status in “resolvconf” package in Ubuntu:
  Fix Released

Bug description:
  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.

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