Unpin box and include apt-get upgrade
ocdtrekkie opened this issue · 5 comments
vagrant-spk should not strongly push using a static box version and also fail to run apt-get, meaning old, potentially buggy or insecure binaries are packaged with apps by default. With the contrib- boxes maintaining vboxsf support, there's no good reason to pin the box to an old version.
According to https://groups.google.com/forum/#!topic/sandstorm-dev/agB-dPf7L6k the 9.3.0 box we pin in the Vagrantfile has an issue with vbguest installation. Probably should just go ahead and remove the pinned version box.
So removing the pinned box config line still boots up VMs using whatever box image you already had downloaded. For new users, they'll get the latest box, but everyone else would need to call vagrant-spk vm box update (which does work!) to get the latest box downloaded. And if they did this after the first vm up (which is when Vagrant tells them there's a newer box), they'd want to vm halt, vm destroy, and then vm up to make sure their VM is created with the latest box.
I tried adding an apt-get upgrade -y into global-setup.sh just prior to installing curl, but it exploded on a question regarding updating grub, which I've seen before. I am thinking we may be able to just exclude grub, I am not sure we care about updating it.
My experience has been that using debian/contrib-stretch64 is a pain. If someone is developing an app which needs a recent version of, say php-fpm, that Debian version is going to install php 7.0 as a default. The WordPress port was getting around this by directly editing sources.list but this was also broken when I came to update it. WordPress recommends PHP 7.3 which is probably not uncommon for modern apps (Laravel needs 7.2.5) and my guess is that packages required for other stacks will also be far behind current stable versions.
Given that stretch is nearing end of life, I would suggest we update to the debian/contrib-buster64 box. This is going to be less painful for new contributors and developers and anything which can be done to ease the process is worth it IMHO.
@codecowboy Indeed, for the Babybuddy package, the developer ended up just switching to buster themselves. This issue is not exactly for that, you are looking for #250 which describes some of the things we need to fix in order to upgrade to buster by default.