It should be simple to re-run the script and have it bring the system to a known state.

[andym]

Aim:

• It should be simple to re-run the script and have it upgrade an existing system or fix a partial install that failed part-way through.
• It should run correctly over a previously installed version 4
• It should run correctly over a half-run version 4
• It should run correctly over a previously installed version 3 (tested on my own existing install)

Decisions:

If a git clone exists, it will be rm-d and cloned again. I thought about doing a git pull, but if people have made bad local changes it’s best to wipe it and pull from a known good source. I thought about checking for local changes, but the build process leaves local files, so the git clone is always “dirty”. I thought about making it halt, but I want people to just be able to run the script and have it work.

If people have already successfully installed in the past, installing base is going to reset it back to beocreate-4ch-blank, which I think is OK as again it’s a known starting point for someone who’s having problems. We also move (but not erase) beoconfig.json to allow people to set-up a system using the guided-setup.

More words than diff here, I expected this to be harder to do!

[tuomashamalainen]

Upgrading an existing system easily is one of the goals we want to tackle in the future. I think this is a good start on that path, and the reasoning for moving existing settings aside and starting fresh is sound (a "soft factory reset").

Upgrading through the GUI, when we add it, should attempt to preserve the "officially supported" settings (mainly not resetting beoconfig and hostnames), because that's just what end users expect from software updates. Maybe that type of upgrade becomes another argument for beocreate-installer (as the GUI uses it behind the scenes), because there's value in both approaches.

One thing to think about is how beocreate-installer could upgrade itself. Currently this is a bit of a chicken-and-egg issue: the installer orchestrates the installation process, but on the other hand it is one of the files in the repository that is cloned to the system as part of the installation. There will be changes to the installation process down the line, obviously, as we add/change features and hopefully expand the source selection. A way to solve this could be a tiny "pre-installer/upgrader" that can always exist outside the cloned repo (/home/pi/ likely), and in theory would never need to change. It will handle installing git in the first place and cloning the repo, then starting the actual installer from inside the repo.

To end this train of thought I'd like to again @andym voice my appreciation for your contribution so far. I originally put beocreate-installer together very quickly to ease the installation of our test setups, and my talents are elsewhere than shell scripting. The recent changes have given me stuff to think about and really elevated the installer closer to where it needs to be – to be worthy of the name "Bang & Olufsen".

[andym]

Thanks @tuomashamalainen ! Glad you're finding it useful. All I'm doing is incrementally hacking away at your existing code. I've been trying to send pull requests which aren't too large, and which leave master in a releaseable state, but which make things a bit better each time. Your swift merging is encouraging.

I'd been thinking about an "upgrade" argument on the command line. I think a reasonable next step is to extract all the blocks to functions, and while install calls all of them, upgrade calls most of them. I think yesterdays work means that the same blocks can be used for upgrade or install.

I hadn't been thinking about an "update" (a self-upgrade of the installer). My .bashrc knows how to git pull itself and restart, so it's certainly possible. You might want to think about tagged releases - otherwise master will always have to be releaseable. Also if you go too far down this route it might instead be better to distribute a .deb which solves problems of versions and dependencies. I've built many many .debs but bever released any to the public so if you do choose to go this way eventually, perhaps I can help a little.

This is a fun project - I'm enjoying the mix of new and old hardware and software involved - bash is the hot-glue-gun of the software world, while that web-app/node for the guided install is a very nice solution. I'm also enjoying the finished result - these CX100's look and sound marvellous.