UX of distributing multiple binaries [take 2]

[dmitry.sinyavin]

I’d resolve the “where to search for binaries” question as the following:

1. Add an optional command line parameter like --workers-path to the main Polkadot binary. That should address some possible corner cases when people want to place those binaries somewhere not in $PATH (I would think of /usr/libexec, for example, as a pretty natural location for such stuff in Debian-based distros).
2. Search in the same directory where the main binary resides. That would address development builds, CI builds, and everything similar, as well as most production installations where everything goes to /usr/bin, /usr/local/bin, or even /opt/polkadot/bin.
3. As the last resort, search in $PATH.

Any objections or better ideas?

[dmitry.sinyavin]

Also wanted to bring up the question of package-based distribution once more.

According to telemetry, if we had an apt repository with a .deb package, it would address the needs of more than 90% of our users. They just do apt-add-repository once and apt install polkadot then, and that’s it, everything works, and they even get totally automatic upgrades if they use unattended-upgrades (which is recommended in server environments). And, considering it’s the official Parity’s Polkadot implementation, it would be quite logical if Parity, not some third party, provided and maintained that repository.

Do we have any strong arguments against such an approach?

[bkchr]

paritytech/polkadot/blob/master/README.md#debian-based-debian-ubuntu

[dmitry.sinyavin]

@bkchr Oh. Wow. So when you told “we shouldn’t build any packages” you meant “there are other people in the company who do that”, not “no packages should ever be built by the company”?

[bkchr]

@bkchr

Second, just because you are writing the guide, doesn’t mean that you can also change the deb packages or dive into the nix packages However, there are already people maintaining these packages and they could use your guide to adapt the packages and update the installation instructions for the respective systems.

^^^

There are people in the company and also people outside of the company who maintain packages.

@bkchr

You still don’t get that I never said that you can not write your script. You can write as many scripts as you like. I don’t care. The point being, that there should be a guide for people so they are not required to read these shitty bash scripts that are full of hacks. And this guide have the priority, what you do afterwards is up to you.

[dmitry.sinyavin]

Okaaay, thanks for the clarification, looks like I wasn’t the only one who didn’t get it right
So it’s one problem less, good to hear!

[rphmeier]

Yeah, it’s important to give the community the tools they need in order to create their own packages. I’m in favor of removing Parity maintaining a script as a bottleneck. I agree with Basti’s position that:

• Parity should write and maintain guides that contain all considerations for installing multiple binaries
• Parity can write a script to make this easier but
• Expect the community to use the guide to create their own packages and images for different distributions