Re: [GNUnet-developers] documentation: Rewriting the Installation Handbook with a focus on simplicity and coverage

[Schanzenbach, Martin]

TL;DR: There are no working binaries because there are not current/regular 
releases. The handbook should not claim what we cannot deliver. There are 
temporary mitigations, however, such as docker images that we could provide 
with 0 overhead given modern CI. Finally, compiling from source is for devs 
only and they should know what they are doing.

Long version:
The reason why docker is a good choice is because of our "release strategy".
GNUnet has not seen a release in ages.
The current "binaries" (deb, rpm?) are too old to be used.
So if user A comes to irc and asks "hey, how to I get the most recent, working 
version?" the answer is:

1. Don't use the binary packages (sic!)
2. Compile and install from git

The latter requires a lot of knowledge and takes time and effort. And then you 
only have it installed along with a huge amount of dev dependencies the 
software does not even need to run!
Imagine user A comes to irc and asks the same question.
The answer could be: "No release, yet. You could use a docker image for the 
current upstream though. Then you just need to run $ docker run gnunet:latest".
(And this answer works regardless of OS)

Again, this is a result from our lack of releases. But thanks to things like 
docker, we could still deliver nightly precompiled images.

The handbook should reflect this:

1. The easy way (for users, docker image)
2. The hard way (for devs, from source)
3. The future way (binary packages/installer) (WIP!)

Eventually this could be changed into:

1. I just want to use it (binary packages/installer)
2. I want to develop! (from source)
3. Optional: Use docker image to run GNUnet without installing


> On 4. Jun 2018, at 10:34, Nils Gillmann <address@hidden> wrote:
> 
> Nils Gillmann transcribed 693 bytes:
>> Schanzenbach, Martin transcribed 10K bytes:
>>> 
>>> 
>>>> On 3. Jun 2018, at 22:33, Nils Gillmann <address@hidden> wrote:
>>>> 
>>>> Hi,
>>>> 
>>>> Schanzenbach, Martin transcribed 6.5K bytes:
>> 
>>>> Ideally it works like this: identify package manager. Look at
>>>> the command you need to run to install it. Done.
>>> 
>>> Well that first requires packages. I do not thing we are there yet so this 
>>> part would be blank.
>> 
>> We are in a good number of Operating Systems. The number can still grow,
>> but it's more than 3.
>> 
>> 
>> 
>> I'll reply to the rest later.
> 
> Okay.
> 
> While I think you missed the point or your understanding of Docker is 
> incomplete,
> here's another take on this:
> 
> traditionally the INSTALL file, which in GNU projects often turned into some
> kind of boilerplate (at least from what I've read), contained the information
> how to install a software.
> I think what you were getting at, is website content.
> 
> I think here's how to split and how I will handle this:
> 
> * I will look at `INSTALL' in the repository and see if I can edit it or even 
> have to
> * Provide an extending document which outlines details for odd ways some 
> Operating Systems
>  which we document.
>  Even Docker falls under 'Can be documented in small textfiles'.
> * Remove the Installation Handbook. We don't really need it. Move its 
> relevant content
>  into the user handbook and other parts.
> * 2019 -> let's write a good website which includes how to simply install 
> GNUnet.
> 
> No one ever reported problems installing GNUnet in binary form. It was always 
> about
> how to run it, how to configure it, etc. The matter of configuration of 
> compile time
> options etc will be part of the developer handbook.
> 
> WDYT?

signature.asc
Description: Message signed with OpenPGP