[Bug 1085862] Re: #DEBHELPER# token is in the wrong place, and other resolvconf postinst nits
Launchpad Bug Tracker
1085862 at bugs.launchpad.net
Fri Jan 18 17:10:16 UTC 2013
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 <stgraber at ubuntu.com> Fri, 18 Jan 2013 11:52:10 -0500
** Changed in: resolvconf (Ubuntu)
Status: Fix Committed => Fix Released
--
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
More information about the foundations-bugs
mailing list