search

d-e-s-o / nitrocli

A command line tool for interacting with Nitrokey devices.
30 stars 10 forks source link

Improve installation instructions #171

Open robinkrahl opened 3 years ago

robinkrahl commented 3 years ago

Currently, we describe three installation methods in the readme: distribution packages, from crates.io and from source. As we don’t really like cargo install, should we really mention it in the readme? And regarding the installation from source, we fail to mention the man page and how to verify the integrity of the tarballs.

Also, I think it would be useful to have all and install targets in our Makefile for easier compilation and installation for end users. install should have a configurable prefix, defaulting to /usr/local.

What do you think?

d-e-s-o commented 3 years ago

As we don’t really like cargo install, should we really mention it in the readme?

I don't feel strongly about including it. With the switch to GitHub actions I think (haven't checked) we should also be able to produce a fully statically linked (including libc) Linux binary targeting musl. At least for me it would be tremendously useful to have that when I really need it, such as when booting into some random air-gapped live Ubuntu/Arch/whathaveyou, and where installing nitrokey-app is just a royal pain in the behind.

And regarding the installation from source, we fail to mention the man page and how to verify the integrity of the tarballs.

Do you want to explain how to install the man page or just that it exists?

Also, I think it would be useful to have all and install targets in our Makefile for easier compilation and installation for end users. install should have a configurable prefix, defaulting to /usr/local.

Hm, how feasible is doing that? Would we just dump everything somewhere below /usr/local? How would we ensure that PATH is set correctly, that the manual page can be found, etc? I didn't really want to open that can of worms, to be honest, because now we are doing that here and when we package nitrocli up.

robinkrahl commented 3 years ago

I don't feel strongly about including it.

If we keep it, I’d at least add the --locked option because cargo install ignores the lock file by default.

With the switch to GitHub actions I think (haven't checked) we should also be able to produce a fully statically linked (including libc) Linux binary targeting musl.

True, though as far as I understand, it is not possible to produce publicly downloadable artefacts with a GitHub action. So I think we would have to push it to some webspace to publish it.

Do you want to explain how to install the man page or just that it exists?

Most importantly that it exists and that it should be installed. As the installation directory is standardized, I would probably include it, but I don’t insist.

Hm, how feasible is doing that?

I think it should be pretty easy to setup.

Would we just dump everything somewhere below /usr/local?

At least the location for the binary and the man page is defined by the Filesystem Hierarchy Standard [0]: $prefix/bin for the binary and $prefix/share/man/man1 for the man page. The shell completion files might be a bit tricky.

[0] https://www.pathname.com/fhs/pub/fhs-2.3.html

d-e-s-o commented 3 years ago

Sounds good. We can give it a shot and see how messy it gets.

d-e-s-o commented 3 years ago

With the switch to GitHub actions I think (haven't checked) we should also be able to produce a fully statically linked (including libc) Linux binary targeting musl.

True, though as far as I understand, it is not possible to produce publicly downloadable artefacts with a GitHub action. So I think we would have to push it to some webspace to publish it.

According to this article both (musl + automatic artifact generation & publishing) should be possible.

robinkrahl commented 3 years ago

According to this article both (musl + automatic artifact generation & publishing) should be possible.

I see, you want to generate the binaries for every release and attach them to it, right? I was thinking about making the binary produced by every workflow run downloadable (which is AFAIK possible on Gitlab but not on GitHub).

d-e-s-o commented 3 years ago

Yeah, I think that would be sufficient for what I had in mind. It's not meant for testing, just when for whatever reason you are in an environment in which you can't download/build/whatever.