alsuren
Manifest option in `Cargo.toml` specifying apt pkgs to be installed in the action
Would be useful for packages like gitoxide who require some system deps, and this would mean we could build packages like that on the actions. Could also make equivalents for other package managers.
That's doable but I have doubt on this approach since this essentially requires cargo-binstall to run any command on install.
Might pose a security issue and not all users want it.
I would personally prefer to not have it and having a static build instead.
How is it a security concern if everything is containerised in an action? But I get that not everyone wants it, it would just mean we could support more crates.
How is it a security concern if everything is containerised in an action?
Many also use this locally on their personal computer, including me.
But I get that not everyone wants it, it would just mean we could support more crates.
I would suggest using static linking as it is far more portable and avoid the trouble.
Also, according to my experience, most binaries fail to execute due to missing libssl openssl.
It's missing often because a new breaking release has made upstream (openssl 1.1 => 3) and installing old openssl might cause the system to uninstall the new one on some systems.
Not sure I encountered this personally with openssl, but definitely has issues with other packages on debian.
Oh right, we had a misunderstanding. I was talking about adding apt pkgs to the GitHub action during build time, not installing them locally.
Oh right, we had a misunderstanding. I was talking about adding apt pkgs to the GitHub action during build time, not installing them locally.
I am a little bit confused.
Aren't you proposing running apt install ... to cargo-binstall right after installing the bins?
I think @Milo123459 is wanting to specify build-time dependencies so quick-install can build packages that have those kinds of requirements.
Good idea, but: could be better to have some kind of external (ie kept here) q-i specific manifest for this so it doesn't require cooperation with the upstream to specify deps and we can assume apt.
(On top of that it could be useful to have some kind of generic (not in q-i or binstall namespaces) spec for defining build-time requirements, but unsure how to do that in a package-manager-independent manner so it can be generally useful.)
Yeah, it could be quite a challenge, but I think it would be 100% worth it. This would mean we could support loads more packages, with very little downside.
@passcod Oh you are right, I thought this is the repository of cargo-binstall