Also, how do we give them a good reason to put it in there?
1 Like
A good reason: IPFS is perfect for distributing packages. Without relying on expensive hosting or a network of mirrors maintained by volunteers splitting the cost of bandwidth limits.
Packages are immutable and content-addressing provides additional layer of security.
Distributing them over IPFS would also make it easier for users of free and open software to contribute (by sharing bandwidth as opt-in).
There is an ongoing discussion about using IPFS in ArchLinux, and even better one about NixOS.
In general, any package manager that downloads data over HTTP could use IPFS (via HTTP gateway), but you need someone to set up continuous automation that downloads updates and publishes them to IPFS/IPNS first.
5 Likes
That indeed is a good reason.
I was also thinking along the lines that if Linux distros came with ipfs, the ipfs Web would be easily available to them. Then if we get enough content creators bigger desktop/mobile OS-es would jump on the bandwagon and implement IPFS into their networking subsystems.
That is certainly the ultimate goal.
But first, there should be a go-ipfs package every popular distribution.
It needs to be up to date and have dedicated maintainer(s).
Not sure what is the current state of this, as I am running go-ipfs in Docker.
1 Like
We have go-ipfs packages in Arch official community repo and AUR. It is also in Snap which is sub-package manager installed on Ubuntu.
Getting it into RH, Debian would be nice but it isn’t something that someone that never packaged for them can do.
1 Like
“but it isn’t something that never packaged for them can do.”
What did you mean under that?
Though, I am not sure why it’s in a snap, because snaps aren’t really meant for system software, and IPFS seems more like system software.
Sorry for that:
it isn't something that someone who never packaged for them can do.
Packaging for Official RH and Debian Repos is complex and long process.
More so if you are doing it for the first time.
I would love to see someone to do it either way.
I’ve said this somewhere before: ipfs has a ton of deps. None of them are packaged either. Official distro packages don’t do things like pulling a bunch of deps from a random source during the build process for good reasons. You need to build from sources or from already packaged dependencies which are built from sources. You need to stick to very strict guidelines about where files are installed etc. and IPFS does not play well with this. It’s always possible to package it, but right now, it would be a huge effort to package it “the right way” in the hopes it can make it to the main lines of the bigger distros.
This reminds me that there was going to be an official go-ipfs tar package with all the sources which should simplify the process.
Nobody said it’s easy.
But then again, it’s still possible, right?
I’d even argue that dependencies like Go itself may benefit for certain distros. Of course, at least I guess, it must be carefully considered, which preinstalled packages are put into the distro, to avoid unnecessary overhead - but from a first glance, distros may benefit from this change so much that, in my opinion, it’s extremely worthy.
In the end, though, I’m still a beginner Linux user only, so I have absolutely no idea, how strict those rules you mentioned are, but I try to keep upp my optimism.
1 Like
If there were integrations throughout the OS (i.e. preconfigured to resolve dweb urls, mount IPFS folders via file explorer, right click to add to IPFS), yes
1 Like
ipfs has a ton of deps
https://www.archlinux.org/packages/community/x86_64/go-ipfs/
4 dependencies, of which 2 are only needed to build the package and 1 being optional. This leaves glibc, which is required for virtually any package anyway. And the large binary size is largely a function of it being written in go.
4 dependencies, of which 2 are only needed to build the package and 1 being optional.
Sure, for arch’s community packages that works. That is never going to work for debian/suse/centos-official-distribution-grade standards.
What do you mean? The only hard install dependency is glibc, and that (or replacements, such as musl-libc) is included in all distributions anyway, since next to all packages have it as a direct or indirect dependency. So the net change from adding IPFS is +1 package, which is IPFS.
2 Likes
Even if it works only for Arch, that’s a victory already.
1 Like
See also the ticket to package IPFS as Debian package. Sure packaging can be dirty work but it’s as important as good documentation to enable adoption. Some data providers even have more strict requirements. For instance next release of Ubuntu LTS will be April 2018. If there is no IPFS Debian package until January 2018, it will unlikely be used until 2021 by agencies that require Ubuntu LTS.
1 Like
Definitely! I’m an openSUSE Tumbleweed user, and would absolutely love it if my OS came with go-ipfs preinstalled. So far it’s not even included in the official software repositories yet, though someone made a custom repo for it in the meantime which is very helpful.