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).