On 9/3/24 8:04 PM, Kent Overstreet wrote: >> Back to Debian. Since each package can only have one source >> *.orig.tar.xz, I would assume that Debian has basically two choices as a >> result of their packaging format: >> >> - package each crate as a system dependency >> - repack each program source after running `cargo vendor`, and upload >> *that* as the canonical source code > > I already provide 'cargo vendor' tarballs. Yes, it's big (thanks to > bindgen), but it's not _enormous_.
Sure. Debian was probably working with the notion that using vendor tarballs makes individual packages a "special snowflake", which is a tempting rationale until you realize you're patching to allow versions that are way too low. > And bindgen is unfortunately the problematic one (and the one that broke > the build) - the semantics of the packed and aligned attributes are > subtle, and bindgen has had difficulty getting them right (due in part > to differences between gcc and microsoft). Heh, no doubt. :) -bindgen = "0.69.4" +bindgen = "0.66" Really makes you think about the wisdom of allowing versions that upstream specifically marked as incompatible (downgrading, not upgrading!) Especially since binding between two languages will inherently tend to violate rust's safety semantics! The entire point of bindgen is to create a "safe" description of C types... > Don't unbundle the other dependencies. They're tiny, and it's not worth > the pain it could potentially cause. Yeah but again this has nothing to do with unbundling, rather, it's about modifying version and disrespecting: - the lockfile - the Cargo.toml If the debian packages were simply the same version as all the Cargo.lock entries, then it would be *unbundling*, but not *modification*. ' It's the modification that's a problem, and specifically, the modification of *required lower bounds*. It might be safe to upgrade a crate, to get a "better" version, but downgrading to get a worse version generally feels pretty silly. Again, Simply running `cargo install --git https://github.com/koverstreet/bcachefs-tools` will totally ignore your lockfile and feel free to update to "newer == better" versions. Perhaps bindgen would even fix more attribute issues. :D But it would always, always, always respect Cargo.toml, which is why Debian did NOT bother doing anything to the lockfile, but did apply a patch to Cargo.toml > The cargo dependency model is _really good_ because it means dependency > updates happen in commits in the consuming package, meaning it's > actually possible to bisect for breakage caused by a dependency update - > that's not something we've had before. And you can do the same with any C build system that isn't "I like Makefiles because I think they are simple to write". You do a dependency update in commits in the consuming package as an update to the version specification of the url+checksum used to download and build C libraries as vendored dependencies. Just like Cargo.lock And like Cargo.toml, you can do the *other* kind of dependency update (also as commits in the consuming package) by updating the *minimum* version permissible (e.g. when consuming a system package). This really is a solved problem in C/C++ and has been for a decade. It has to be, if for no other reason than that Windows developers ***do not have a choice*** as there is no such thing as system dependencies. That is why vcpkg exists (and using it involves adding a manifest to your Windows project describing the exact pinned versions of your dependencies to go ahead and build). -- Eli Schwartz
OpenPGP_signature.asc
Description: OpenPGP digital signature
