<div dir="ltr">Following on from my previous post about dylibs vs rlibs, I figure we have these options for rust library packages:<div><br></div><div>1. Ship dylibs (and rlibs)</div><div><br></div><div>2. Ship rlibs only</div><div><br></div><div>3. Ship rust source (like golang library packages)</div><div><br></div><div>--------</div><div><br></div><div>Re (1):</div><div>I think (1) is out until we can provide ABI stability between compiler releases somehow (see previous post).</div><div><br></div><div>Re (2):</div><div>As far as I can work out (and I've asked a few upstream rust devs), rlibs have all the same ABI compatibility issues as dylibs across compiler versions.  This means that if we shipped *-dev packages with rlibs, it would look like this:</div><div>- libfoo-dev Depends on specific rustc/libstd upstream version, produces an rlib file that installs somewhere into the rustc search path(*)</div><div>- There is no libfoo  (and no shilibs files)</div><div>- bar-tool would Build-Depend on libfoo-dev (of correct libfoo upstream version) but not on libfoo (since there is no such thing).</div><div><br></div>(*) rustc search path for rlibs is $prefix/lib/rustlib/$target/lib, but I think this would be an easy/safe thing for us to extend in our rustc if we wanted to look somewhere else for some reason.<br><div><br></div><div>This looks pretty good from a Debian packaging standpoint, although library maintainers would need to rebuild fairly quickly following rustc releases (we could also NMU since no source change would be necessary - assuming no rustc syntax changes).</div><div>I think cargo assumes source code, however (but I'm not sure on this point - worth following up on) - it would be nice if we could make cargo work with just an .rlib and some sort of stub manifest.</div><div><br></div><div>Re (3):</div><div>This is the easiest and safest option, given that golang has already demonstrated this path is acceptable.  In this version, all library packages are just a copy of their source code installed into a semi-standard place.</div><div>- libfoo-dev ships library source code.  Has a dependency on specific compiler version range, if it has to deal with breaking rustc syntax changes - similar but not same as (2)</div><div>- There is no libfoo (and no shlibs files) - same as (2)</div><div>- bar-tool Build-Depends on libfoo-dev but not on libfoo - same as (2)</div><div><br></div><div>The advantage of this approach, is that cargo can be made to work with it by a small patch to cargo to look in /our/rust/lib/install/path/* for additional toml manifests, a lot like the existing .cargo/config `paths` option.</div><div><br></div><div><br></div><div>So I think our options are (2) or (3).  I think we should run these options past rust+cargo upstream since they both (presumably) require at least small patches to cargo and it would make sense to match what other distros might do.</div><div><br></div><div> - Gus</div><div><br></div><div>(Thanks for reading.  I've been thinking about this for a few weeks now and it was time I brought it to wider discussion)</div></div>