New Installation method

[davidcawork]

Hi all 😄 !

The truth is that I found the installation process on a virtual machine with Ubuntu 16.04 quite complicated (Due to its slowness and failures in the call of ./autogen.sh ). Analyzing the scripts, note that there were many parts that can be ignored since they are partly the decision of each user the IDE to use, use desktop icons, wallpaper, change the login, create a user p4...

I made this script for personal use since it made the installation much easier and did not over modify the native machine. I do this pull-request because I think it can be useful for more people and it seemed selfish to keep the script only for me.

Best,

---

• This script solves the problem that the call to the shellscript (autogen.sh). More info about the bug

[davidcawork]

I understand what you mean. It would be possible to add parameters to the installation script to be able to choose between this type of quick installation and the native installation that was later. For example:

• For the native installation with Vagrant: sudo install.sh
• For quick installation: sudo install.sh -q

In this way you just have to change the vagrant file: (Delete lines 27 and 28, and add this line config.vm.provision "shell", path: "install.sh")

---

Another way would be to check if the user is Vagrant to change the installation method to the native. Something like that:

#!/bin/sh

if [ "$USER" = 'vagrant' ]; then
        #Native installation method
        . . . 
fi

I sincerely like the first, What do you think?

I get with it and I update you here the progress :smile:

Best,

[davidcawork]

Dear @jnfoster 😄

First of all I feel sorry for delaying me so much, I wanted to verify the correct functioning of the new installation process. According to the requirements that you gave me to be able to maintain the native installation method in Vagrant, I have developed the first option, that the script supports parameters for the installation. There will be two modes, the native method (root-bootstrap.sh + user-bootstrap.sh) and the quick method.

Both methods are included in the same installation script (install.sh). You can access them based on parameters. By default the installation method will be the native.

• To run native method (default): sudo ./install.sh or sudo ./install.sh -n
• Tu run quick method: sudo ./install.sh -q

In addition, an additional help parameter was added to reflect this information to the user. It can be accessed via: sudo ./install.sh -h or sudo ./install.sh -? .

The vagrant configuration file had to be modified to adapt it to the new installation method. To verify that it works, I have done several installation tests. Feel free to try it yourself 😄

• Installation in Vagrant with the native method ✔️
• Installation in Ubuntu 16.04 VM with the native method ✔️
• Installation in Ubuntu 16.04 VM with the quick method ✔️

I think that in this way the installation script is more maintainable and opens new possibilities to create new installation methods since all the blocks are collected in functions.

Best,

---

• ⚠️ Currently the Vagrant installation is broken (master), since the (root-bootstrap.sh + user-bootstrap.sh) paths were updated but not in the Vagrantfile. It would be a good idea to update it as soon as possible. I have already corrected it in this pull-request.

[jafingerhut]

My apologies for not doing something more with this PR long ago, but the current state of affairs are that the scripts in this repository are still only tested to be working if you use them in the context of a vagrant up or vagrant up dev command, and NOT tested working when the scripts are used outside of these steps.

However, currently the top level README also provides a direct link to another repository that does have scripts that can be run on a freshly installed Ubuntu Linux system of several recent versions, on the account of any user, not only a user called vagrant. Those scripts are also tested working every month.

Having an independent set of scripts in this repository that duplicates this work seems out of scope right now, unless someone wants to volunteer to create updated versions of such scripts, and test them periodically. Thus closing this PR. Thanks for the offer.