Arch Linux User Repository

ArchLinux Pi-hole is not officially supported by Pi-hole project. In case of bugs and malfunctions please DO NOT file a report upstream.

First of all check if the wiki (https://wiki.archlinux.org/index.php/Pi-hole) can help then ask here for assistance and tips.
When it will be excluded that the problem does not depend on ArchLinux we will file a bug upstream.

to update to pi-hole 6, please use pi-hole-core pi-hole-ftl and pi-hole-web packages.

oh I forgot. I'm not arguing about the possible answers not because I feel guilty in any way or at least intimidated but simply because I don't feel like it and I don't care

I apologize for my choice of words, I was quite flabbergasted when i stumbled upon this.

@Namarrgon - you have a valid point about the script not conforming to the Arch Way, but you should consider just stating the facts rather than including language that can be inflammatory.

The rest is less important, personal preference, stylistic, pedantic, nitpicky or I simply don't know what it's doing.

nothing else?

/usr/bin/chown -R pihole:pihole /etc/pihole

You already have a tmpfiles.d snippet, why not use it to also set the owner here, too?

[ -e /etc/pihole/.useIPv6 ] && rm /etc/pihole/.useIPv6
[ -e /etc/pihole/adlists.list ] && rm /etc/pihole/adlists.list
[ -e /etc/pihole/dns-servers.conf ] && rm /etc/pihole/dns-servers.conf

The configs are getting wiped without warning. Let the admin decide what to do with them, they know best.

sudo -u pihole bash /opt/pihole/gravity.sh --force > /dev/null 2>&1;
[...]
sudo -u pihole bash /opt/pihole/updatecheck.sh;

Unconditional automatic updates over the internet inside of a pacman scriptlet. You also don't know the local network setup so this might hang for an unpredictable time until some part of the network stack times out. Again, let the admin decide when to update, they know best.

grep -qF 'QUERY_LOGGING=' /etc/pihole/setupVars.conf || echo 'QUERY_LOGGING=true' >> /etc/pihole/setupVars.conf

Why can this not be patched during the creation of the package? Why is this run on every update? Maybe the admin can do this if/when they need it?

find /etc/pihole -type f ! -name '*.pacsave' ! -name 'pihole-FTL.conf' ! -name 'pihole-FTL.db' ! -name 'gravity.db' -delete

You can't delete files that don't belong to the package. This is the admin's job, don't mess with their system.

id -u pihole > /dev/null 2>&1 && userdel -f pihole

This is a NO-NO, security wise. The 'pihole' UID will get recycled eventually and then the new owner of it suddenly controls the old files associated with that UID. Let the admin handle group removal, they know best.

first of all: hi Namarrgon.
and... i'm sorry what?

This .install script is an abomination. Why is it deleting configs from /etc? Why is it connecting to the internet for updates? Why is it deleting user accounts? Why is it editing configs? All these tasks should be left to the admin. If some of these steps are required for the operation then they should be documented.

The package builds fine for me in a clean chroot, but when I go to install the package on a machine that does not have a working internet connection it seems to hang on the install script at gravity.sh and I am guessing the updatecheck.sh script might cause issues also.

I am sure this is a chicken and egg issue on how I am installing my system. Would it be safe to not run those two until the first run? I can patch my version of the package, but I am curious if there is any reason to check for updated when installing the package and not just wait until runtime to initialize the database (I am assuming that is what the gravity.sh script does).

@graysky in post_update e post_install:

echo -e "\e[1;33m==>\e[0m Updating 'versions' file...\e[0m"
sudo -u pihole bash /opt/pihole/updatecheck.sh;

/etc/pihole/versions is automatically updated by that script...