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 <n...@n0.is> wrote: > > Nils Gillmann transcribed 693 bytes: >> Schanzenbach, Martin transcribed 10K bytes: >>> >>> >>>> On 3. Jun 2018, at 22:33, Nils Gillmann <n...@n0.is> 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
_______________________________________________ GNUnet-developers mailing list GNUnet-developers@gnu.org https://lists.gnu.org/mailman/listinfo/gnunet-developers