Ah! Well done, I didn’t, I wouldn’t know where to start, I thought it was confusing enough when part of the emonpi repo.
The net result of that position is that each user may have a slightly different sdcard build depending on the status or the debian repos at the time of install irrespective of any further updating of the emonsd.
Either not running an update/upgrade at all (not recommended) or running an update/upgrade at each emonsd update would put everyone on a common image and update path. Updating once at time of inception and never again is IMO the worse scenario as it potentially means no 2 images are the same making experience, reliability and debugging a tad random.
I thought following the big discussion regards using apt-get upgrade or dist-upgrade and the fact only recent (non-mosquitto repo?) images are updated via emoncms, the OS was safe to update.
It’s a bit odd that we are pursuing Python v3, dropping Jessie and possibly php 7.0 etc for security reasons as these will no longer get security patches, when we do not pull in any patches to the OS or installed packages (eg Python) for the life of the emonSD image which could be years and years!!!
My main concern is that users may be updating at points where we havent checked the compatibility of new versions of dependencies, didn’t that happen with redis once? If a new version of redis or associated clients fail, that could break further updates… requiring command line level fixing…
If there is general consensus that the risk is minimal and outweighed by risk of software not being up to date then Im happy to include apt-get update in the update scripts.
I agree with all those points, the decision is essentially yours, you/we either need to fully support “updated OS” and aim to fix any nasties as and when they surface, pronto. Or you need to only support from a fixed point that everyone is using until you change that base point. The choice is yours I was just surprised by the current position where (as you suggest above) users could find themselves in hot water due to installing today just as easily as updating today.
I just think it should be always updated or never updated rather than just once at install as the repos can change at anytime. Whilst the one sdcard pre-built image approach was easier to manage on this front, I do think the “correct” thing to do is to try and keep the OS and packages up to date, but that could mean extra work without notice.
This whole can of worms is where approaches like docker come in I guess, where you can specify the exact versions of the main dependencies etc, without that kind of thing its a bit of gamble really isn’t it… @emrys is working on a balena docker image at the moment which we hope to use as part of our own managed deployments - in large part to try and improve this whole update process (in the context of managed deployments)… I don’t understand enough about it yet though to know if that can apply more generally to OEM users and a future emonSD replacement
You could say that but we should be keeping a breast of changes rather than holding back.
I’m totally put off the whole docker approach because of the way OEM uses PIO, things can become stagnant. We should be using the latest JeeLib for example. Because a particular old version was used at some point, we are now using the old versions with greater frequency to maintain compatibility. Had what ever hiccup triggered the rollback was resolved at the time, all devices would be running the latest JeeLib and no version management would be needed. I do see the potential benefit of “fixed” points, but I never imagined them being fixed for all eternity
I was just surprised by the current position where (as you suggest above) users could find themselves in hot water due to installing today just as easily as updating today.
