Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve installation instructions #171

Open
robinkrahl opened this issue May 2, 2021 · 6 comments
Open

Improve installation instructions #171

robinkrahl opened this issue May 2, 2021 · 6 comments

Comments

@robinkrahl
Copy link
Collaborator

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
Copy link
Owner

d-e-s-o commented May 2, 2021

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
Copy link
Collaborator Author

robinkrahl commented May 2, 2021 via email

@d-e-s-o
Copy link
Owner

d-e-s-o commented May 2, 2021

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

@d-e-s-o
Copy link
Owner

d-e-s-o commented May 14, 2021

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
Copy link
Collaborator Author

robinkrahl commented May 14, 2021

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
Copy link
Owner

d-e-s-o commented May 15, 2021

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants