# Perfecting Rust Packaging

**URL:** <https://internals.rust-lang.org/t/perfecting-rust-packaging/2623>\
**Category:** tools and infrastructure\
**Created:** [September 10, 2015, 11:05pm UTC](https://internals.rust-lang.org/t/perfecting-rust-packaging/2623 "2015-09-10T23:05:59Z")\
**Posts on this page:** 1\
**Showing post:** 67

<div class="post-metadata">

**Author:** ![gus](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/gus/32/2924_2.png) [@gus](https://internals.rust-lang.org/u/gus)\
**Post date:** [October 15, 2015, 12:27am UTC](https://internals.rust-lang.org/t/perfecting-rust-packaging/2623/67 "2015-10-15T00:27:06Z")

</div>

> [@ahmedcharles](#):
>
> I would have thought that the -dev package would contain the source and the binary package would be effectively empty

My nomenclature might be a bit confusing. I've been somewhat carefully trying to use these terms without ever actually defining them anywhere:

- "source package" - the input to the (Debian) packaging build process. In Debian this is a \*.dsc and some tarballs, in Redhat (I think) this is a srpm. No-one other than the distro packager(s) ever see these.
- "binary package" - the output from the (Debian) packaging build process. This is a \*.deb or \*.rpm. This is what you apt-get/yum/whatever install.
- "library package" - a binary package that contains a library in some way. I see above I haven't used better terms than "-dev" and "not -dev" to describe the way regular C dynamically linked libraries are typically split into multiple binary packages 😕
- "application package" - a binary package that contains an end-user (Rust) application. It most likely depends on several "not -dev" library packages.

So following the plan described earlier, a Rust library would be distributed in a "binary package" that bundles the Rust source. Since it is only a build-time dependency, it would be called "foo-dev" (or "foo-devel") and there would be no "foo" (not -dev) unless there are some additional data files, etc required at run-time to use the library.

To continue your example, a hypothetical `librust-openssl-sys-dev.deb` package would include the Rust source and depend on (non-Rust) `libopenssl-dev.deb` for the unversioned C `*.so` used at link time. (Non-Rust) `libopenssl-dev.deb` depends on `libopenssl.deb` and perhaps other libraries, but that isn't really any of our business. There would be no `librust-openssl-sys.deb` package. A hypothetical `cargo.dsc` source package might build-depend on `librust-openssl-sys-dev.deb`, which would also pull in the (non-Rust) `libopenssl-dev.deb`. Building the package would produce `cargo.deb`, which would have a run-time dependency on (non-Rust) `libopenssl.deb` to pick up the real openssl shared library and no run-time dependency on (Rust) `openssl-sys` at all because it has been statically linked. As @mzabaluev points out, the packaging build tools can usually deduce the run-time dependencies automatically (basically by running `ldd` over everything and seeing what dynamic libraries were actually linked).

---

_[View the full topic](https://internals.rust-lang.org/t/perfecting-rust-packaging/2623)._