[Git-commits] [grml/grml-live] acf12d: GRMLBASE/98-clean-chroot: fix resolvconf symlink h...

[Michael Prokop]

  Branch: refs/heads/master
  Home:   https://github.com/grml/grml-live
  Commit: acf12d4123bd68f4e8eefa0c9fa10e5fbb0ac31b
      https://github.com/grml/grml-live/commit/acf12d4123bd68f4e8eefa0c9fa10e5fbb0ac31b
  Author: Michael Prokop <mika at grml.org>
  Date:   2020-01-28 (Tue, 28 Jan 2020)

  Changed paths:
    M etc/grml/fai/config/scripts/GRMLBASE/98-clean-chroot

  Log Message:
  -----------
  GRMLBASE/98-clean-chroot: fix resolvconf symlink handling + get rid of resolvconf workarounds

resolvconf no longer supports usage of /etc/resolvconf/run as such,
instead things are supposed to live in /run nowadays.  Quoting from
resolvconf's debian/changelog:

| resolvconf (1.80) unstable; urgency=medium
|
| [...]
|
|   [ Steve Langasek ]
|   * 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.

So /etc/resolv.conf being a symlink pointing to
/etc/resolvconf/run/resolv.conf no longer works, instead it needs to
point to /run/resolvconf/resolv.conf.

Given that our resolvconf code dates back to 2007 (see commit 1d1565d0e49),
while at it get rid of the workarounds, which don't seem to be needed
anymore.

Tested this change with builds against Debian/stretch (resolvconf 1.79),
Debian/buster (resolvconf 1.79) and Debian/bullseye (resolvconf 1.82).

Closes: https://github.com/grml/grml/issues/142


  Commit: ef6dc82d6987250cd2b5f70a25336cfef40076b3
      https://github.com/grml/grml-live/commit/ef6dc82d6987250cd2b5f70a25336cfef40076b3
  Author: Michael Prokop <mika at grml.org>
  Date:   2020-01-28 (Tue, 28 Jan 2020)

  Changed paths:
    M etc/grml/fai/config/files/etc/apt/sources.list.d/debian.list/DEBIAN_STABLE

  Log Message:
  -----------
  DEBIAN_STABLE: use buster-backports instead of stretch-backports

Debian/buster is the current stable release, there's no point in
enabling stretch-backports there.

FTR: we could set it to 'stable-backports' instead, though then
apt/apt-get/... will complain about it:

| W: Conflicting distribution: http://ftp.debian.org/debian stable-backports InRelease (expected stable-backports but got buster-backports)


Compare: https://github.com/grml/grml-live/compare/422c49bc62f3...ef6dc82d6987