Would this start ipfs daemon as root?

@ion1 this is supposed to be used with systemctl --user start ipfs.

There's no sane way to drop privileges for ipfs inside the unit file.

@kpcyrd could you add a small readme, or installation instructions for the service? It looks good to me otherwise.

@kpcyrd This LGTM, i'll wait for a check from @jbenet and then we can merge.

• These already exist elsewhere. see https://github.com/ipfs/examples/tree/master/examples/init
• let's not bloat this one repo any further.
• add a link to the page if you want.

(so, no i dont think we should merge this)

@jbenet the reasoning here is that it make it easier on package managers to set up their package builds if everything needed for the install is in one repo. Although if you're against merging this then we should make a working init script and put it in the examples repo you linked.

sure, we should maybe have a repo with all the various init scripts and point there from this repo.

A second repo would break the workflow of packaging. go-ipfs made it into the arch community repo, they maintain a copy of ipfs.service in their repo now.

i agree with @kpcyrd here, i think that everything needed for an 'installation' of go-ipfs should be in the same repo, if we ship bash completions in the misc folder, why not also have various init scripts there too?

+1 to including init scripts directly in the repository.

This repo will eventually be broken apart into a bunch of smaller repos. and, another repo (or perhaps it will be this one, if that is its future) will pull in (from other repos) the pieces necessary to build and sign a full release. inc building artifacts like various platform installers. thus clean separation of concerns.

Also, i will not start dictating what this repo does based on what any package manager needs. theres tons of them and it will be a nightmare to try and please everybody. it is TRIVIAL to make another repo, pull this one in as a submodule and make any desired changes / file additions. This is a much better and more scalable approach as it allows all the package managers / platforms to do whatever they need to do, control the entire thing, and without conflicting with us or each other at all. (so maybe go make go-ipfs-dist-arch and put ipfs.service in there)

if we ship bash completions in the misc folder, why not also have various init scripts there too?

i've been wanting to remove those, and the random bins too. they should not crowd this repo, and they should have their own clean, simple version control. We can trivially link to those repos, and provide installation of the tools via ipfs itself.

i've been wanting for some time, and i plan to make soon, a "toolchain" that is shipped via ipfs itself and can be installed (individually, or together) -- this toolchain will include things like multihash, multiaddr, graphmd, bsdash and more.

• Most users DO NOT install go-ipfs from this repo
• Most users install from our provided binaries
• Those users should still be able to access all these tools (inc ipfs.service) trivially easy, via a link or downloading via ipfs itself.
• I want to make this repo entirely about integrating all the Go modules into a single binary, and running full integration tests on it. Though we're very far from that, commits here should eventually mean just updating modules (code or tests).

closing based on comments above.

Distros started shipping their own ipfs.service now, you have to coordinate with downstream if there are any changes you want to make.