nitrocli
nitrocli copied to clipboard
Improve installation instructions
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?
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
andinstall
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.
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
Sounds good. We can give it a shot and see how messy it gets.
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.
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).
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.