The seconds commit should fix the tests. Not sure why we had fresh_install=false in a test that should test a fresh installation.

I think we should still update the package cache when the meta package is updated, so all new dependencies are up to date.

This would be possible too. We would only need to signal package_manager_detect that we are invoking from the update script or not.

How does this compare to #6274 ?

In the current implementation or the one suggestion by @darkexplosiveqwx ?

#6274 removes also the building and installing of the dependency package before doing an update - which might fails because some 'installer dependency' is not installed.

Ah, okay. Maybe something like apt cache policy <dependency package> | grep version and compare that to the /etc/.pihole/ <package metadata version> and "do things" if the proposed updated metadata is higher than the installed package version?

fresh_install was introduced as a replacement for useUpdateVars, but the logic was "reversed" to make the names make sense.

Replaces the variable useUpdateVars with fresh_install and flips the logic around. useUpdateVars used to make sense as a name when a user could seed a setupVars.conf file, but this is no longer the case and the naming is not so clear.

So I just changed them in the tests, too.

It was added in the first place with this commit
cedd1a2

Back then, the test added configuration to setupVars.conf to automatically install the web interace and the web server. This is no longer needed.

Would #6292 #6298 be a more graceful solution?

I'm not sure if this is the way to go. While it addresses the suggestions from above, it adds 100 lines of code. I'm not sure if this is worth it, considering 'normal' users will only benefit from it during an update which is not happening that often.

I would go another way as a middle ground: only update the cache before we install the meta package initiated by the install script, but not from the updater.

ADD
I only noticed now, that we do the cache update only on apt based systems, reducing the necessarity to do it at all even more from my view.

The last two changes allow to update the cache when building/installing the meta package from the installer script, but don't do when building/installing from the update script.
I intentionally did not squash to allow easy reverting to a previous state depending on how we decide the functions should work.

While it addresses the suggestions from above, it adds 100 lines of code.

But it saves about 160 lines with each pihole -up that contains no meta data changes and saves SD activity caused by installing the same version of the package again. (when no Pi-hole updates available)

If there is an update to core repo with NO meta packages changes or just an FTL update it would save double the lines and double the SD activity. Currently all package management steps are done twice is these two scenarios, once at the beginning of update.sh and again during basic-install.sh. see here

and would also ensure that

we had users who removed e.g. git which were left with a broken update.1

does not happen as well.

I'd like to go for this PR for now as it improves the situation. The massive change in #6298 needs some very thorough review and testing and that's going to take time.

Considering this is a QOL fix and not a bug fix, I'm good with what Yubi has written.

@mwoolweaver:

But it saves about 160 lines with each pihole -up that contains no meta data changes

Where do you see these 160 lines?

This is the output that I see with this branch code:

root@pihole:/etc/.pihole# pihole -up
  [✓] Building dependency package pihole-meta.deb
  [✓] Installing Pi-hole dependency package

  [i] Checking for updates...
  [i] Pi-hole Core:     up to date
  [i] Web Interface:    up to date
  [i] FTL:              up to date

  [✓] Everything is up to date!

I think I like the idea of always creating/updating the dependency package. It gives us a guarantee that the update will function because it will add the packages that we know we need to run the update. This accounts for the case where a user removes a package that we need from the system, and it's really a light process to run. I don't see it generating a lot of writes to any drive or storage media.

Here's a verbose run of the update code:

+ build_dependency_package
+ rm -rf '/tmp/pihole-meta_*'
+ local tempdir
++ mktemp --directory /tmp/pihole-meta_XXXXX
+ tempdir=/tmp/pihole-meta_JaZox
+ chmod 0755 /tmp/pihole-meta_JaZox
+ is_command apt-get
+ local check_command=apt-get
+ command -v apt-get
+ pushd /tmp
+ rm -f /tmp/pihole-meta.deb
+ mkdir -p /tmp/pihole-meta_JaZox/DEBIAN
+ chmod 0755 /tmp/pihole-meta_JaZox/DEBIAN
+ touch /tmp/pihole-meta_JaZox/DEBIAN/control
+ echo 'Package: pihole-meta
Version: 0.4
Maintainer: Pi-hole team <[email protected]>
Architecture: all
Description: Pi-hole dependency meta package
Depends: awk,bash-completion,binutils,ca-certificates,cron|cron-daemon,curl,dialog,dnsutils,dns-root-data,git,grep,iproute2,iputils-ping,jq,libcap2,libcap2-bin,lshw,netcat-openbsd,procps,psmisc,sudo,unzip
Section: contrib/metapackages
Priority: optional'
+ local 'str=Building dependency package pihole-meta.deb'
+ printf '  %b %s...' '[i]' 'Building dependency package pihole-meta.deb'
  [i] Building dependency package pihole-meta.deb...+ dpkg-deb --build --root-owner-group /tmp/pihole-meta_JaZox pihole-meta.deb
+ printf '%b  %b %s\n' '\r' '[✓]' 'Building dependency package pihole-meta.deb'
  [✓] Building dependency package pihole-meta.deb
+ popd
+ rm -rf /tmp/pihole-meta_JaZox
+ install_dependent_packages
+ local 'str=Installing Pi-hole dependency package'
+ printf '  %b %s...' '[i]' 'Installing Pi-hole dependency package'
  [i] Installing Pi-hole dependency package...+ is_command apt-get
+ local check_command=apt-get
+ command -v apt-get
+ '[' -f /tmp/pihole-meta.deb ']'
+ eval 'apt-get -qq --no-install-recommends install' /tmp/pihole-meta.deb
+ printf '%b  %b %s\n' '\r' '[✓]' 'Installing Pi-hole dependency package'
  [✓] Installing Pi-hole dependency package
+ rm /tmp/pihole-meta.deb
+ printf '\n'

This pull request has been mentioned on Pi-hole Userspace. There might be relevant details there:

https://discourse.pi-hole.net/t/pi-hole-core-v6-1-3-released/81168/1