| |
|---|
| | idea is to allow multiple verisons of your toolsets to exist under |
|---|
| | `${INSTALLDIR}`. You simply create a symlink in that directory named |
|---|
| | `${TOOLS}` to point to the version you want. This makes certain |
|---|
| | automation use cases with `tsshbatch` or `ansible` somewhat simpler. |
|---|
| | |
|---|
| | HOWEVER, during the actual build process described here, *it is |
|---|
| | important that the directory be named canonically*. That is, it |
|---|
| | should be located and named *where you intend to deploy it*. The |
|---|
| | binaries care - a lot - about where to look for their libraries and |
|---|
| | such. So, for instance, if you are deploying to `/foo/bar/tools`, |
|---|
| | don't build it under `/foo/bar/tools-20180324`. You build under |
|---|
| | `/foo/bar/tools`. The release process will create a tarball that |
|---|
| | contains `foo/bar/tools-YYYYMMDD` which you can untar to other |
|---|
| | machines (under `/foo/bar/`). You can then either just rename it to |
|---|
| | `tools`, or create a symlink called `tools` that points to it. |
|---|
| | |
|---|
| | Paying attention to this most likely bite you the first time you untar |
|---|
| | a bootstrap tarball to perform a full build. DAMHIKT. |
|---|
| | |
|---|
| | |
|---|
| | ## Building The Bootstrap Image |
|---|
| | |
|---|
| |
|---|
| | |
