Open abentley opened 2 years ago
I don't think cargo-deb can do anything about this. As far as this crate is concerned, all systems are the same.
Issues like deps versions and glibc shenanigans are related to specifics of the build, and cargo-deb merely calls cargo build --release
and doesn't micromanage the builds.
In practice you may get away with building the whole project on the oldest OS that you support, using a container or a VM.
Right. That makes sense. At the same time, using a VM or container is exactly what cross-rs automates, so it seems like there's an opportunity for integration between the two projects.
Anyhow, would you welcome an update to the readme?
I suppose a small mention will be ok, but I wouldn't want to end up with a comprehensive list of what this crate doesn't do :)
Is it possible to add some parameter to cargo-deb just to use cross
instead of cargo
?
It would be very helpful.
There's --no-build
for this. build with cross however you want, and then package with --no-build
.
This is only tangentially related but I couldn't find a better place to ask (but feel free to point me to such a place): I am studying the overall approach of cargo-deb
and it appears the package is created fully manually without any use of dpkg
or any higher-level helpers provided by Debian. My initial guess at the reason was that it would allow creating the package on different versions of Debian/Ubuntu or even on different Linux distributions. But based on the above discussion this does not appear to be the case (plus there are a few calls to dpkg
and dh_*
machinery). So can anyone (perhaps @kornelski ?) provide some rationale for going with this "from scratch" approach? Thanks in advance for any insight!
My rationale is that I use macOS and develop code on macOS. I simply can't install dpkg on my daily driver OS :)
While cross-building for glibc-based distos is a major hassle, especially if C dependencies are involved, it's still doable. I have some pure-Rust projects that I build for musl and package on macOS host.
Secondary issue is that deb-related tools aren't available out of the box, and need to be installed manually, pulling in their own dependencies, and are tied to particular Debian version, so they may be outdated and fiddly to deal with. It is a bit of a NIH syndrome, but pure-Rust tools are easier to use by Rust projects, and this is true for cargo-deb development as well as downstream Rust users of cargo-deb.
I've made cargo-deb run on Windows only because it's funny.
Given #51 (cargo-zigbuild) perhaps this ticket is adequately addressed?
I simply can't install dpkg on my daily driver OS :)
FWIW, brew install dpkg
does work on macOS.
With Ubuntu 22.04 LTS out, I'm now using this on my development machine, while still wishing to support 20.04 LTS. It seems like others would be in the same boat. While --target x86_64-unknown-linux-gnu seems like part of the solution, any package dependencies aside from libc would also need to be accounted for. It seems like a job for cross-rs, except that cross doesn't seem to support cargo-deb.
Anyhow, some documentation on supporting alternate distro-releases (even "not currently supported") would be helpful.