Quickstart and install corrections

[fscheiner]

Should fix #14.

[fscheiner]

@msalle, @ellert, @maarten-litmaath: Some remarks and questions for the install guide:

[...]
===== Updating a GCT Installation =====

For the GCT the package repositories in general always include the GCT component
versions that were included in the latest available GCT version, except for
Debian, where the package repositories for the stable distributions include the
GCT component versions that were included in the latest GCT version that was
available before the freeze for the respective stable version of Debian took
place. Debian unstable (aka Sid) instead always includes the GCT component
versions that were included in the latest available GCT version like the other
Linux distributions.

In addition fixes for broken GCT packages or security fixes for GCT components
are included in the package repositories **also** in between GCT releases.
[...]

Mattias, is this correct as I wrote it, especially the specifics for Debian stable and the situation for broken packages and security fixes?

Also, how does it look for Debian stable, when a package breaks during a release life-cycle or needs a security fix: Do the fixes then have to be backported to the component version used in the specific stable Debian release?

[...]
==== Updating an Installation ====

The updates available in the native packages described above are also
published as source packages in 
https://repo.gridcf.org/gct6/[our repository]. 
To install update packages, follow their download link, untar
them, then configure them with the same prefix as your original
installation and install them as described above.
[...]

Updated source packages actually only reach our repo when we make a release. But as per our release guide we make a release soon for a broken component or ASAP for security fixes. Broken packages are of no concern for people that install the GCT from the "Source Installer".

[fscheiner]

The Travis CI build fails, because we currently don't share encrypted environment variables with forks. But this also means, we don't get a check result for PRs. I don't know if sharing these encrypted env vars with forks could allow anyone who forks the gct-docs repo to get push access to our repo by getting the CI to put the contents in the clear with scripts from a PR.

UPDATE: Ok, as per https://travis-ci.community/t/iv-undefined-in-openssl-invocation/6614/8 sharing these encrypted vars would make them "public" in a way, as the code in a PR has to be considered untrusted.

UDPATE2: Maybe it's best to deactivate builds for pushed PRs. This because the build actually results in a push to the branch containing the HTML files and not into some temporary branch IIUC. But this also means that we would be limited to the view of the ADOC files for a PR and couldn't check the HTML result until we merge the PR.

Relevant information from Travis CI settings page:

Security settings

The pull request (PR) settings are applicable for git-based pull
requests from forks of this repository filed against this repository.

Sharing data with forks allows more comfortable collaboration
when collaborators are forking from your repository, but builds
initiated by the pull requests from forks against your base
repository get access to your decrypted environmental variables
and/or keys.

Not sharing secrets is more secure but makes it much less
convenient to collaborate using forks. 

[fscheiner]

@ellert, @msalle, @maarten-litmaath: Any chance for a review until tomorrow afternoon? If not I'll merge this then as is. We can always correct any problems later.