Move scripts/GRMLBASE/40-deborphan towards DEBORPHAN class as file 10-whitelist If the DEBORPHAN class is used before the GRMLBASE class when invoking grml-live, then any whitelisting executed via scripts/GRMLBASE/40-deborphan will happen too late, which is not obvious and surprising. Instead let's move scripts/GRMLBASE/40-deborphan towards the DEBORPHAN class and name it as "10-whitelist".
deborphan: drop deprecated packages We don't ship shadowfs + bsdtar since ~2011, libewf1 and libstdc++2.10-glibc2.2 no longer exist in any supported release, so let's do some housekeeping.
deborphan: add workaround for transitional package dnsutils dnsutils became a transitional package with version 1:9.16.2-3 (as present in current testing (bullseye) and unstable): | % rmadison dnsutils | dnsutils | 1:9.9.5.dfsg-9+deb8u15 | oldoldstable | amd64, armel, armhf, i386 | dnsutils | 1:9.10.3.dfsg.P4-12.3+deb9u5 | oldstable | amd64, arm64, armel, armhf, i386, mips, mips64el, mipsel, ppc64el, s390x | dnsutils | 1:9.10.3.dfsg.P4-12.3+deb9u6 | oldstable-new | amd64, arm64, armel, armhf, i386, mips, mips64el, mipsel, ppc64el, s390x | dnsutils | 1:9.11.5.P4+dfsg-5~bpo9+1 | stretch-backports | amd64, arm64, armel, armhf, i386, mips, mips64el, mipsel, ppc64el, s390x | dnsutils | 1:9.11.5.P4+dfsg-5.1 | stable | amd64, arm64, armel, armhf, i386, mips, mips64el, mipsel, ppc64el, s390x | dnsutils | 1:9.11.5.P4+dfsg-5.1+deb10u1 | stable-new | amd64, arm64, armel, armhf, i386, mips, mips64el, mipsel, ppc64el, s390x | dnsutils | 1:9.16.2-3 | testing | all | dnsutils | 1:9.16.2-3 | unstable | all It depends on bind9-dnsutils, which is available only in current testing (bullseye) and unstable: | % rmadison bind9-dnsutils | bind9-dnsutils | 1:9.16.2-3 | testing | amd64, arm64, armel, armhf, i386, mips64el, mipsel, ppc64el, s390x | bind9-dnsutils | 1:9.16.2-3 | unstable | amd64, arm64, armel, armhf, i386, mips64el, mipsel, ppc64el, s390x If we switch our GRML_FULL package list from dnsutils to bind9-dnsutils, then we would only support testing (bullseye) and unstable but not any older release. To avoid this, mark dnsutils as "keep" in deborphan, so it does not end up in the not_installable list (and mark failing tests in Jenkins/CI).
SW: Drop qemu-kvm (qemu-system-x86 being its replacement) from GRML_FULL qemu-kvm is in `Section: oldlibs` and deborphan removes the package anyway, even though we mark it as `--add-keep`. There's no point in putting further effort into this, as qemu-system-x86 provides everything what's needed nowadays.
deborphan: add qemu-kvm to list of packages which are never to be reported In commit ec12218051e8c1 we added qemu-system-x86 as underlying dependency for qemu-kvm, now qemu-kvm is considered for removal. This seems to be the case because qemu-kvm depends on qemu-system-x86 and and even though we explicitely ask for both packages to be installed, then qemu-kvm is considered for removal. Let's avoid this by adding qemu-kvm to the list of packages which are never to be reported by deborphan, then it's not automatically removed via DEBORPHAN/98-clean-chroot. Noticed via "grml-live-missing-packages.test_missing_packages_qemu-kvm" in Jenkins daily builds.
Implement -D option to set configuration directory; fai.conf: don't set variables grml-live is setting via cmdline now; provide new scripts to deploy configuration files (/etc/inittab, /etc/locale.gen, /etc/modules); rework and adapt cleanup scripts accordingly [Closes: issue880] Get rid of /etc/grml/fai/config/grml/grml-cleanup_chroot*. and also drop deprecated checks. Do NOT clean up /home/grml and /root unless using the RELEASE class. This might make some users happy I guess. :) Deploy /etc/inittab, /etc/locale.gen and /etc/modules using according fcopy commands. Now shipping new scripts GRMLBASE/16-depmod, GRMLBASE/41-modules, GRMLBASE/91-update-pciids, GRMLBASE/92-update-freshclam, GRML_SMALL/90-update-alternatives, GRML_SMALL/98-clean-chroot, RELEASE/98-clean-chroot, REMOVE_DOCS/98-clean-chroot and LATEX/98-clean-chroot. While at it build /etc/grml/fai/config/files/etc/apt/sources.list/GRMLBASE based on /etc/grml/fai/apt/sources.list to get rid of editing config files on the fly. This is a major Q/A rework, giving the user a much better handling of scripts using FAI's class concept.
Make all shell scripts using /bin/bash instead /bin/sh to be able to FAI's environment. /usr/lib/fai/subroutines sadly is a /bin/bash script. As we want to be able to use functions like ifclass we have to use /bin/bash in all our scripts (even though they're POSIX ones), otherwise people using dash as /bin/sh will notice something like: /GRMLBASE/25-locales: 23: ifclass: not found in their FAI's shell.log. Thanks: thermoman Signed-off-by: Michael Prokop <mika@grml.org>
40-deborphan: Add exception for libewf1 and libstdc++2.10-glibc2.2
Drop Latest change lines, add initial support for Debian/squeeze
Make sure /etc/grml/fai/config/scripts/GRMLBASE/40-deborphan does not fail
Add /etc/grml/fai/config/scripts/GRMLBASE/40-deborphan