-
Notifications
You must be signed in to change notification settings - Fork 10
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
Comments
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
Do you want to explain how to install the man page or just that it exists?
Hm, how feasible is doing that? Would we just dump everything somewhere below |
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. |
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. |
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
andinstall
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?
The text was updated successfully, but these errors were encountered: