Orphaning bcachefs-tools in Debian

Post by JackSlateur » Sat, Aug 31, 2024, 1:18 PM UTC

viraptor wrote: post #36

JackSlateur wrote: post #29

Earlier quoted context omitted.

And if my kernel crashes ? And if whatever library bugged, oh well, random people can access my systems ? And if my bgpd bugged, oh well, we just inject random routes et forward data randomly ? Makes no sense.

Your kernel has no external library dependencies. Relaxing library requirements can introduce security issues when the dependency behaviour changes, so I'm not sure what the argument is. If your bgp is bugged, yeah it sucks, but it's recoverable. We're using encrypted traffic these days to ensure that even captured traffic is safe. The difference here is that data corruption is not recoverable.

Post by koverstreet » Sat, Aug 31, 2024, 1:21 PM UTC

haileys wrote: post #48

koverstreet wrote: post #43

I would rather something not be packaged at all than packaged badly; this whole experience reads like a lesson in what not to do. What the author left out in his blog post is that I specifically explained why this was going to be an issue and what was going to happen when he and I first talked about Debian packaging; and why for a package that needs to work correctly for the system to boot (fsck, mount helper, encryp…

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…

Post by foobarqux » Sat, Aug 31, 2024, 1:22 PM UTC

JonChesterfield wrote: post #3

This would be a good one for Rust enthusiasts to weigh in on. The issue raised is that some program written in rust insists on a very specific version of various dependencies. If other people change the metadata, it builds and seems to run ok with different versions. (Developer on reddit clarifies that it builds and does the wrong thing, and recommends dropping Debian as a solution). Linux likes to pack a finite set…

Post by aragilar » Sat, Aug 31, 2024, 1:29 PM UTC

viraptor wrote: post #44

aragilar wrote: post #34

Earlier quoted context omitted.

I would expect it to be the opposite (especially for a linux file system): you want to test with as wide a variety of versions as possible, because that what you're going to encounter in the real world. If your code only works in a limited set of cases, what happens when you mount the file system on a different system, is the file system going to be trashed?

These are all compile time dependencies in this case. You're not going to encounter a variety of versions - that's exactly what the strict version bounds are doing. The app will be built with the tested version and everyone gets the same results.

Post by acka » Sat, Aug 31, 2024, 1:31 PM UTC

yshui wrote: post #41

This is pretty dumb on Debian's part. First of all I don't understand why they insist crate dependencies must be pulled from their repository. They are just source code, not built binary. AFAIK there is no other distro that does this, what they do is that they would download crates from crates.io (`cargo vendor` is a command that does this automatically) and build against that. Arch does this, Gentoo does this, NixOS…