Hacker News Reader

Comment by JoshTriplett | Hacker News Reader

I'm curious if there were any significant responses to the tooling/ecosystem questions regarding packaging and integration with Linux distributions.

I'd like to provide an application written in Rust in major Linux distributions. "cargo install" will not work, both because it depends on network access, and because it pulls in dependencies from outside the distribution. Similarly, many distributions have policies against bundling library sources in the application. There needs to be a straightforward way to turn a source package with a Cargo.toml file into a package for Debian and Fedora that depends on other packages corresponding to its Cargo dependencies (and C library dependencies).

View on HN

Cargo install was never intended to be used that way. It's for things useful for Rust developers, not for people who use a program who happen to be written in Rust.

There's a few things at play here. For "build from source" distros, we've been making some changes to make it easier to package rustc. Namely, instead of relying on a specific SHA of the compiler to bootstrap, starting with 1.10, it will build with 1.9, and 1.11 will build with 1.10. This is much, much easier for distros. As for Cargo dependencies on those packages, we'll see. There's a few ways it could go, but we need the compiler distribution sorted first.

A second is that we'd like to eventually have tooling to make giving you a .deb or .rpm or whatever easier: https://github.com/mmstick/cargo-deb is an example of such a tool. This won't necessarily be good enough to go into Debian proper; I know they tend to not like these kinds of tools, and want to do it by hand. But "Hey thanks for visiting my website, here is a thing you can download and install", these kinds of packages can be made with this kind of tooling.

In general, it's complex work, as then, these issues are also different per distro or distro family. We'll get there :)

I was more looking for a path to producing Policy-compliant packages for Debian and other distributions.

Do you know of anyone working on that right now, and how I can help?

https://internals.rust-lang.org/t/perfecting-rust-packaging/... is the big internals thread about it; weighing in there is a good entry point. Thanks!

> This won't necessarily be good enough to go into Debian proper; I know they tend to not like these kinds of tools, and want to do it by hand.

No, not "by hand". By automation provided by distribution.

And you know what it takes for this automation to be able to build a DEB out of the source tree? A "compile" command that (a) does not touch network, ever, and (b) does not expect dependencies to be downloaded into the source tree nor $HOME/.whatever, but allows them to reside somewhere in /usr/lib.

It's that simple, yet most of the language-specific package managers completely fail at this or at least make this building mode awkward.

BTW, the same stands for RPMs, and virtually any binary packaging system.

  > No, not "by hand". By automation provided by distribution.

My understanding is that the _configuration_ is usually written by hand, and then the automation takes care of the actual build.

  > And you know what it takes for this automation to be able to build a DEB out of the source tree?

(a) is already covered, as is (b). That said, we're still working on making it easier.

> My understanding is that the _configuration_ is usually written by hand, and then the automation takes care of the actual build.

There's absolutely nothing wrong with auto-generating the packaging files in the debian/ directory, as long as the uploaded package contains the generated versions. I'd love to see a tool that can generate a Policy-compliant Debian source package from a Cargo crate, ready for upload.

> (a) is already covered, as is (b). That said, we're still working on making it easier.

I've seen the proposed plan for addressing (a) and (b), namely shipping the full source code of library crates in the -dev package. Has this been implemented, in a way that Cargo can use?

I would too, I didn't realize that it was achievable, but even as a long-time Debian user, I haven't payed close enough attention to these policies, it seems.

Oh no, I meant that Cargo itself will already not hit the network, and you can configure exactly where it downloads sources. I wasn't aware of any "Cargo can use a .deb for source" plans.

> I wasn't aware of any "Cargo can use a .deb for source" plans.

You got it a little wrong. Cargo should not expect sources in -dev packages. It should expect precompiled libraries (static ones).

> (a) is already covered, as is (b).

I'm glad to read this. The only thing that remains then is to keep programmers (those writing applications in Rust) from breaking either of these points...

> That said, we're still working on making it easier.

...and making the documentation clear how to use the build tool in this manner, even for sysadmin who doesn't write Rust code (I don't know the current state of Cargo's docs; maybe it already achieved that).

It's a tooling issue, not those using the tooling: meaning, it's up to the Cargo devs to not break the behavior, and we have incentives not to do so.

There are people working on this, here's an announcement for a deb plugin to Cargo:

https://www.reddit.com/r/rust/comments/4ofiyr/announcing_car...

I hadn't seen this. Thank you for sharing.

I included it as a challenge when I filled out the survey. So there's one. ;)

Reply on news.ycombinator.com