On Tue, Sep 03, 2024 at 08:31:16PM GMT, Eli Schwartz wrote: > 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...
Yeah, I think it's been pretty well established by this point that mistakes were made. Hopefully we're finally on a track to doing better :) > > 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. But given that different packages probably won't be specifying the exact same versions of dependencies, so debian isn't going to have the right one, and most of these dependencies are _tiny_ - why bother with the enormous hassle? Not everything tiny bit of code needs to be a distro-level package... > 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 Yeah, cargo still has some bugs: the modern thinking on how to do this style of packaging 'right' has been evolving fairly recently. Cargo.lock should really not be changed by anything but 'cargo update', and if I was less lazy I'd file a bug about htat.
