I’m afraid I disagree with both points. Firstly the writing into place is NOT easily updated in comparison to the symlink method as it requires further steps, be it cp, mv or sed etc, with the symlink method, once the changes are pulled in (git pull is required for either method) the changes are complete there are no “steps” at all.
Secondly, overwriting using sed (during updates) is potentially an ever increasing string of updates, if we set direction x to abc, then decide it should be def, any update script will need to sed “abc” to “def”, but then if it needs to be changed to xyz, maybe not all setups have the first update yet, so moving forward you need to either keep adding edits “abc” to “def” then also “def” to “xyz” or add some form of “abc or def” to “xyz”, this method could get real messy and cause issues, alternately you might rewrite the whole service unit, would that be on every update like the emonpi FW or just when there are changes, how would you test for changes when the content is potentially different for each setup (paths etc).
Plus, the “correct” way to “edit” systemd unit files is to add an edit file, it frequently comes up that we should not be editing service units. So I would understand that to imply that all (say) emoncms_mqtt.service units to be identical across all installs and then any local changes to be in a separate edit file, you could argue that when a service unit source code is modified (ie global upgrade and improvements to the overall service unit) that is not an “edit” and quite rightly that revised unit should replace the current unit (not be an additional edit file). By using the symlink method, changes made at install time to path’s would stick beyond any replaced service unit as the changes are in an external edit file, the new incoming service file doesn’t need customising for each install (eg paths).
Quite the opposite, it really simplifies things, the concept might be tough to get your head around at first, but it is simpler to install, simpler to update and simpler to navigate.
I assumed that to be non-negotiable, or at least a hard sell so I have avoided commenting about the core emoncms folder. I already symlink that into place myself. The main advantage to this (aside from all repos in one place) is for development purposes, I can have several emoncms repo folders and several vhosts and chose/change which versions of emoncms are served by each vhost purely through symlinks, to do this I needed to make a minor edit so that emoncms(s) look for settings.php in it’s parent folder (usually the vhost root folder), I don’t think there’s any demand for this ability, I’m just outlining the flexibility and the fact I already do it that way, but I did not expect the location to change on the emonSD.
No, I don’t think so. emoncms_mqtt.php is a emoncms helper script, it has no purpose if emoncms isn’t running. emonhub can be installed alone, besides, /usr/share was the proposed location for when emonhub was to be Debian packaged, I think /usr/local/bin/ might be more suitable for emonhub. It seems you already adopt this path and symlinking method to the wifi-check
pi@emonpi:~ $ ls -la /usr/local/bin/
total 164
drwxrwsr-x 2 root staff 4096 Apr 23 11:57 .
drwxrwsr-x 10 root staff 4096 Jun 27 2018 ..
-rwxr-xr-x 1 root staff 2060 Apr 23 11:57 log2ram
-rwxr-xr-x 1 root staff 13796 Oct 4 2018 lwrfmqtt
-rwxr-xr-x 1 root staff 31988 Oct 4 2018 paho_c_pub
-rwxr-xr-x 1 root staff 27012 Oct 4 2018 paho_cs_pub
-rwxr-xr-x 1 root staff 27088 Oct 4 2018 paho_cs_sub
-rwxr-xr-x 1 root staff 27788 Oct 4 2018 paho_c_sub
-rwxr-xr-x 1 root staff 13396 Oct 4 2018 paho_c_version
-rw-r--r-- 1 root staff 675 Apr 23 11:57 uninstall-log2ram.sh
lrwxrwxrwx 1 root staff 26 Oct 22 2018 wifi-check -> /home/pi/emonpi/wifi-check
I’m certainly open to ideas regards the emonhub.py symlink (location), if it’s going to be the single oddball then perhaps for consistency it should be called direct in /opt? Where do you plan on installing L2R? Are you going to use the existing L2R “download zip and install” or are you interested in the “clone&symlink” mods I proposed to make? I see emonhub more akin to log2ram than to the other emon services. They are both Python, both run independent of emoncms and are essentially the only 2 things you need to install to a Raspbian image make a “rock solid gateway” style emonBase.
Agreed, can we try and keep some distinction between the new installer, the new updater, fixes that need rolling out to all (eg sorting the /var/log filling) and improvements that maybe rolled out to previous images (eg L2R), the lines seem to get a bit blurred. and (for example) logrotation not being looked at on the existing images because L2R is being discussed and/or fixes to problems that won’t exist in the new installs being included in the new updater.
@TrystanLea can you also look at Permanent "Raspberry Pi Booting..." after failed emonPi Update
Maybe with the new install method looming, we should consider starting a fresh, potentially (but not deliberately) breaking backward-compatibility to get the best solution moving forward, ie fix it once and for all, rather than being restricted by whats happened in the past. In contrast to your 10-20 year sdcard lifespan, Glyn seems to think users should be starting a new image and new sdcard at a much faster frequency (from github Mariadb will not start after a dist-upgrade · Issue #1202 · emoncms/emoncms · GitHub)
if we were to use upgrade in place of dist-upgrade it would limit the operational life of an emonPi (image) to whatever the LTS is for security updates and we might all have still been running wheezy! Even stretch LTS expires in 2022, if you do not use dist-upgrade, it will remain “stretch” for ever, even when support expires.
I would recommend that in 2022 the user would be best to back up their data and move to a fresh SD card with the latest emonSD card build with a vanilla build of Debian Buster.
I’m not convinced that users that buy an emonSD at the end of 2021 would be happy with that approach but if the intended lifespan is going to be shorter and changing base image regularly is the recommended route to keeping an image up to date, then supporting older images becomes a little less important. Currently the “safe-update list” is just 2 significantly different images Jessie RO and Stretch RW (the latter buildguide wasn’t documented) that span less than 2years (Oct2017 ->)
I’m just pointing out that currently the “I recommend downloading the latest image and installing to a new sdcard” line is used so frequently for relatively minor issues, that backwards compatibility is clearly not as big a concern as it should be. Whilst we are currently in a “just start again” era, lets at least mull over the option of totally starting again now, once and for all rather than perhaps rushing out another short lived solution.
.