4 ms·

Thanks for taking the time to comment here! > So then he breaks the build by switching to the packaged version of bindgen, an old unsupported version. Could b

Thanks for taking the time to comment here! > So then he breaks the build by switching to the packaged version of bindgen, an old unsupported version. Could bcachefs-tools solve this problem upstream of distros by releasing a source tarball with the bindings already generated, so that you can use whatever version of bindgen you want, and bindgen is not needed at all when building from this release tarball? This would be similar in nature to traditional autotools approach where some amount of pre-compilation is done to produce a release tarball from what actually lives in the source repository. It's also what I do for some of my ffi crates. I have a script in the root of the repo which regenerates the bindings, but when published to crates.io, the bindings are already generated and bindgen is not part of the build downstream of my crate.

koverstreet 2y ago
I already provide tarballs with vendored dependencies - I did this for Fedora, so that package builds wouldn't have to download anything. I'm not going to special case the bindgen bindings because this really isn't a bindgen specific issue - this could just as easily been any other dependency.
- haileys 2y ago
  Speaking from practical experience, bindgen is a particularly heavyweight dependency. It requires libclang to be available and also adds a considerable amount of time to the compile. If it makes compiling the software easier - and end users compiling the software themselves would benefit here as well as distro maintainers - then it would seem like a pragmatic move to me.
  - koverstreet 2y ago
    This really isn't about bindgen. Any time a dependency is changed, the package version should be bumped and retested. This is a massive improvement in reproducibility, bisectability and our ability to QA. Before this model, bisecting breakage that was a result of a change in library 'a' breaking something in consumer 'b' was effectively impossible; now it is. What Debian and Fedora have been doing is a big step backwards, this whole 'unbundling of dependencies' (that were going to be statically linked anyways) needs to die.
    - brnt 2y ago
      > What Debian and Fedora have been doing is a big step backwards, this whole 'unbundling of dependencies' (that were going to be statically linked anyways) needs to die. They, and most others, have been doing that since their respectively beginnings, and for good reasons: everybody expects distros to fix security issues, which is greatly aided by ensuring an-as-small-as-necesary dep tree and thus a single version of any particular dep. Changing that isn't impossible, but I am not aware of any distro that's managing this and be widely considered 'stable'. How can distros change while keeping up their end which is stability and robustness in the face of bugs and security issues?
      - cesarb 2y ago
        > They, and most others, have been doing that since their respectively beginnings As I explained on another comment of mine (https://news.ycombinator.com/item?id=41409199 https://news.ycombinator.com/item?id=41409199), it's not since their beginning, but since a particular zlib security incident which showed them the risks of vendored libraries. Any discussion of vendoring policy which does not consider that incident is necessarily incomplete.
        brnt 2y ago
        How long ago was that? And did they quantify the problem?
        koverstreet 2y ago
        That's very nearly a solved problem at this point; I get notified by bots (github, mainly) if a dependency has as a security vulnerability, and then it's very nearly a one click action to do a cargo update and commit the new lockfile. The distro people could've been working on the tooling for automating this at the distro level (and some people in debian are doing work that would enable this); we don't need to go this insane "unbundle everything" route.
        brnt 2y ago
        Before broadband, and before forges like github with free CI and bots, which is all fairly recent, distros packaged everything was a godsend, not insane.

koverstreet 2y ago

I already provide tarballs with vendored dependencies - I did this for Fedora, so that package builds wouldn't have to download anything. I'm not going to special case the bindgen bindings because this really isn't a bindgen specific issue - this could just as easily been any other dependency.

haileys 2y ago
Speaking from practical experience, bindgen is a particularly heavyweight dependency. It requires libclang to be available and also adds a considerable amount of time to the compile. If it makes compiling the software easier - and end users compiling the software themselves would benefit here as well as distro maintainers - then it would seem like a pragmatic move to me.
- koverstreet 2y ago
  This really isn't about bindgen. Any time a dependency is changed, the package version should be bumped and retested. This is a massive improvement in reproducibility, bisectability and our ability to QA. Before this model, bisecting breakage that was a result of a change in library 'a' breaking something in consumer 'b' was effectively impossible; now it is. What Debian and Fedora have been doing is a big step backwards, this whole 'unbundling of dependencies' (that were going to be statically linked anyways) needs to die.
  - brnt 2y ago
    > What Debian and Fedora have been doing is a big step backwards, this whole 'unbundling of dependencies' (that were going to be statically linked anyways) needs to die. They, and most others, have been doing that since their respectively beginnings, and for good reasons: everybody expects distros to fix security issues, which is greatly aided by ensuring an-as-small-as-necesary dep tree and thus a single version of any particular dep. Changing that isn't impossible, but I am not aware of any distro that's managing this and be widely considered 'stable'. How can distros change while keeping up their end which is stability and robustness in the face of bugs and security issues?
    - cesarb 2y ago
      > They, and most others, have been doing that since their respectively beginnings As I explained on another comment of mine (https://news.ycombinator.com/item?id=41409199 https://news.ycombinator.com/item?id=41409199), it's not since their beginning, but since a particular zlib security incident which showed them the risks of vendored libraries. Any discussion of vendoring policy which does not consider that incident is necessarily incomplete.
      - brnt 2y ago
        How long ago was that? And did they quantify the problem?
      - koverstreet 2y ago
        That's very nearly a solved problem at this point; I get notified by bots (github, mainly) if a dependency has as a security vulnerability, and then it's very nearly a one click action to do a cargo update and commit the new lockfile. The distro people could've been working on the tooling for automating this at the distro level (and some people in debian are doing work that would enable this); we don't need to go this insane "unbundle everything" route.
        brnt 2y ago
        Before broadband, and before forges like github with free CI and bots, which is all fairly recent, distros packaged everything was a godsend, not insane.