On: Orphaning bcachefs-tools in Debian

[JackSlateur]

  if you deal with filesystems, you really want strict versions

How are doing everybody else ? What is specific with filesystems, here ?

This is a bad dependency management, nothing more. Vendoring is a PITA.

[viraptor → JackSlateur]

Level of potentially messing up. If you have a chat app, relax the deps and it crashes - oh well. But if you have a tool which can cause data loss, you really want to be sure everyone's running what you tested.

It's similar to why restic (backup software) has official, static, reproducible binaries in their releases.

[swinglock → viraptor]

Oh well, it was probably just a crash in my Internet connected software where users can just sent inputs to be processed on my machine.

RCE would have been worse than file system bugs, as it leads directly to a superset of problems including potentially losing all your files.

[JackSlateur → viraptor]

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.

[viraptor → JackSlateur]

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.

[JackSlateur → viraptor]

Linux uses at least libc

[viraptor → JackSlateur]

Linux kernel doesn't use libc. Libc provides the interface for userspace to call the kernel.

[JackSlateur → viraptor]

It does includes its headers (stdlib.h, at least), in various subsystems.

[viraptor → JackSlateur]

In user space tools and tests only. The kernel part does not include stdlib.h anywhere. Nowhere where it matters in the context of "And if my kernel crashes?"

[JackSlateur → viraptor]

You are right, thank you for the insight

[JonChesterfield → JackSlateur]

Filesystems are complicated and have nasty failure modes. Strict versioning reduces the impact of software development QoI properties, i.e. that basically all code is substantially wrong.

[aragilar → JonChesterfield]

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?

[viraptor → aragilar]

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.

[aragilar → viraptor]

There's at least 3 different versions that can happen (the filesystem version, the kernel version (including stable backports), and the tooling version). I'm presuming udev being a dependency means bcachefs links to that (which will be different on different OS versions).

[viraptor → aragilar]

Those are completely different things than the dependencies you can make a choice about. You have to handle different filesystem/kernel versions regardless - you don't get a choice here.