Looks like some things got mixed up here:
-
apt-transport-https is and was never required since Stretch, as it is integral part of APT nowadays. This is just a transitional dummy package and hence can be skipped: https://packages.debian.org/bullseye/apt-transport-https
-
lsb-release is not required when you know that you are on Bullseye. Use bullseye instead of $(lsb_release -sc) to create or adjust APT sources explicitly. The letter is only useful for generic documentations/guides, which do not target a specific distro or distro version.
-
ca-certificates and curl are pre-installed on every distro I know, including DietPi. Without the first, you wouldn't even be able to use apt-get, at least when APT sources use HTTPS (default on DietPi).
But the most important part is the PHP repo and using PHP8.0: Not sure where the info comes from that this would be required, as I would strongly recommend to use PHP7.4 shipped by Debian Bullseye natively, as long as you do not know precisely about the impact of installing PHP8.0 via Ondrej's repository, how to migrate and update PHP configurations and webserver/CLI configs/commands, deal with APT package conflicts etc. The OP had PHP8.0 installed manually, which has nothing to do with Bullseye. But, indeed on an upgraded Debian, it is required to remove PHP7.3 manually, so that the Pi-hole installer pulls PHP7.4 on a repair.
Additionally, until next Pi-hole release, the Lighttpd deflate module needs to be installed, else the installer exits abruptly when attempting to restart the Lighttpd service.
So to anyone who lands here to get current stable Pi-hole running on Debian Bullseye (or DietPi Bullseye), skip all of the above and instead and instead do, if it is an upgraded Debian with existing Pi-hole:
apt purge --autoremove '*php7.3*'
apt install lighttpd-mod-deflate
PIHOLE_SKIP_OS_CHECK=true sudo -E pihole -r
or if it is a fresh OS without Pi-hole/PHP installed:
apt install lighttpd-mod-deflate
curl -sSfL 'https://install.pi-hole.net' | PIHOLE_SKIP_OS_CHECK=true sudo -E bash
After next Pi-hole release, the compress directives are removed from its Lighttpd config and deflate compression is done via drop-in configuration from /etc/lighttpd/conf-enabled/, which is installed with the module If you use the blocking page actively (neither default, nor would I recommend it), this may be the preferred situation to speed up assets transfer to new clients a little. Else, you may apt purge --autoremove lighttpd-mod-deflate again, as for a single user low traffic web interface, where assets are stored in browser cache on first access, there is not much point to have transfer compression.
If you are on DietPi, dietpi-software can be used to (re)install Pi-hole without the above workaround on Bullseye already, including of course the fact that it is not the official install method, hence support relies more on us than on Pi-hole support team.
