Aptitude Installer

[expede]

Summary

Problem

Linux installs are currently a very process

Impact

There is much confusion about which version to run, what are the supported Linux versions, &c

Solution

Much like the web, you generally only support so many platforms. The strategy here is to add to build pipeline, and write an Aptitude installer for:

• Ubuntu
  • Two most recent versions
  • Two most recent LTSes

At time of writing, this would be:

• Ubuntu 16.04-LTS
• Ubuntu 18.04-LTS
• Ubuntu 19.04
• Ubuntu 19.10

[dholms]

Spent a good chunk of time looking into this. Much more frustrating than I thought. So to get a package on Apititude, you need to create a repository that a user can add to apt (add-apt-repository), so they can then find and install your package. The de-facto way to do this is launchpad. The process there is:

• activate a ppa
• create a source package
• sign with GPG key
• upload to that ppa

The key here is: Launchpad doesn't host binaries, it hosts source files, that it then compiles so that it can distribute binaries. I looked into building a source package for a good amount of time before emerging more confused than I went in. This comment sums up my experience quite nicely: https://github.com/jordansissel/fpm/issues/170#issuecomment-5970366

The good news: Building a deb package is very easy. fpm makes bundling a binary into a deb package a breeze. Double click to install or apt install ./fission-1.23.0.deb and boom the binary is at /usr/bin/fission.

Apt repositories themselves are not limited to source packages, only launchpad. I'm currently looking at other options like aptly which give a toolkit for managing Debian repositories. We could host our own on s3 for instance.

Other options include:

• distributing the packaged .deb: download & double-click to install
• a one-line install script (ie "copy this into your terminal" which then downloads & runs a bash script that takes care of install)
• distributing the file as we're doing now. unzipping a file, and doing a mv fission /usr/bin/fission is not that scary for linux users
• doing it the ipfs way which is essentially the above^^ but wrapped in an install.sh script

[MCTaylor17]

[I posted something similar on the Talk forum (deleted) but this seems like a more apt place to discuss 😉]

As a stop-gap (and potentially ongoing basis) how would you feel about distributing the binary as a CID? The installation guide starts with installing IPFS which is a pretty solid lead in:

---

[IPFS installation]

# Initialize IPFS
ipfs init

# Start IPFS
ipfs daemon

In a new terminal, install the Fission CLI

# Download Fission CLI
ipfs cat Qm...xYz > fission.gz.tar

---

The tarball is 7.5MB , but for the price of 34MB, you can one-line it:

ipfs cat Qm...zYz > /usr/local/bin/fission

Keeping the CID fresh would add to the release process, but it feels “thematically correct”. It's also a great way to onboard the uninitiated to IPFS.

[bmann]

We have to figure out the rest of the toolchain and have binaries for different platforms, but I do like the IPFS one liner.

It means that IPFS definitely has to be installed and working!

[MCTaylor17]

It means that IPFS definitely has to be installed and working!

Yup! If there's a problem with ports or firewalls etc, they'll need to resolve those first.

[dholms]

I like the sound of this quite a bit. IPFS being required to download actually adds a nice "check" in front of the install. IPFS is required for the CLI to do anything useful, so i don't really see this being a downside. It keeps Fission from being blamed for ipfs issues :stuck_out_tongue_winking_eye:

It does add some extra legwork to the release process (and right after Ben just finished azure pipelines :sweat_smile:)

I'll try to think of a way to streamline that process a bit

[dholms]

made a little bash script to help with this:

mkdir -p /tmp/fission-release
rm -rf /tmp/fission-release/*
cd /tmp/fission-release

echo Fetching releases...

curl -s https://api.github.com/repos/fission-suite/cli/releases/latest \
	| grep "browser_download_url.*zip" \
	| cut -d : -f 2,3 \
	| tr -d \" \
	| wget -qi -

unzip macOS-10.14.zip -d mac > /dev/null
unzip ubuntu-16.04.zip -d linux >/dev/null

echo Adding to IPFS...

echo Mac:
ipfs add -Q mac/fission-cli-exe

echo Linux:
ipfs add -Q linux/fission-cli-exe

Grabs the latest releases, adds them to ipfs, and outputs the CIDs.

A couple of UX downsides from this:

• possible connectivity issues in that a user will need to discover our ipfs peer in order to find this CID
• ipfs get Qm..... > /usr/local/bin/fission will not save fission as an executable. So we can't online this. We either need to serve a tarball to preserve permissions or get the user to chmod the binary

Another related option:

• we can fission up binaries so that the latest binary is always at linux-cli.fission.name/macos-cli.fission.name. This solves the connectivity issue but does not solve the 2 commands required issue. It also takes away the "cool" factor of getting binaries with ipfs

[expede]

@dholms .deb files also let us specify dependencies to install, right? That's probably the most in line with POLA.

@MCTaylor17 that's a super cool strategy 👍

Since they have slightly different audiences and tradeoffs, and we do need to figure out native distribution:

[MCTaylor17]

Some good points @dholms . A couple thoughts:

get the user to chmod the binary

chmod, is pretty routine for most linux users so I don't think this is a huge hit. It's also part of the existing instructions so it's basically a wash.

a user will need to discover our ipfs peer in order to find this CID

True, although each download also becomes a potential peer...