Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Orphaning bcachefs-tools in Debian

jonathancarter.org

Post reply on HN
Print view View original

21–30 of 224 posts

Re: Orphaning bcachefs-tools in Debian

#21

Post by agwa »

viraptor wrote: post #5
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…

This isn't Rust specific. The same issue exists in all languages where the versions can be restricted at project level. It's an issue in Debian because they can't handle multiple concurrent versions (beyond renaming the package) and want every package built without internet access. But that same issue affects Ruby, Python, etc. if the project specifies strict versions. And if you deal with filesystems, you really wan…

The author would be fine with vendoring. The problem is that Debian doesn't allow it.

Re: Orphaning bcachefs-tools in Debian

#22

Post by nubinetwork »

viraptor wrote: post #5
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…

This isn't Rust specific. The same issue exists in all languages where the versions can be restricted at project level. It's an issue in Debian because they can't handle multiple concurrent versions (beyond renaming the package) and want every package built without internet access. But that same issue affects Ruby, Python, etc. if the project specifies strict versions. And if you deal with filesystems, you really wan…

> This isn't Rust specific. The same issue exists in all languages where the versions can be restricted at project level

Can confirm, I occasionally use an ai program that has to hard code all of their python dependencies, because it's the only way to get it to compile, let alone run properly... and then they go and change the underlying package manager, and figure out they have to hard code even more... it's a bloody mess, but thankfully you can just run it as a docker container once it's all working...

Re: Orphaning bcachefs-tools in Debian

#23

Post by haileys »

cogman10 wrote: post #18
viraptor wrote: post #5

Earlier quoted context omitted.

This isn't Rust specific. The same issue exists in all languages where the versions can be restricted at project level. It's an issue in Debian because they can't handle multiple concurrent versions (beyond renaming the package) and want every package built without internet access. But that same issue affects Ruby, Python, etc. if the project specifies strict versions. And if you deal with filesystems, you really wan…

It should be noted that, particularly for rust, it's a silly policy as rust does not support dynamic linking of rust libraries. All rust applications are statically linked. So trying to force all projects using foo onto the same version of foo is just a huge headache with no real benefit to anything.

It remains a problem for source packages, which are an important part of Debian necessary for offline and reproducible builds.

Re: Orphaning bcachefs-tools in Debian

#25

Post by [deleted] »

JonChesterfield wrote: post #13
JackSlateur wrote: post #8

Earlier quoted context omitted.

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.

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.

[deleted]

Re: Orphaning bcachefs-tools in Debian

#26

Post by Sesse__ »

londons_explore wrote: post #4

So I guess the gauntlet is now down for any other maintainer to come and decide they do want to package it for debian/ubuntu...

Not really.

Debian has a Rust policy, which among others prohibits this kind of extreme vendoring. Upstream insists on exact versioning (thus requiring vendoring), including hacked-up versions of some upstream crates, and also insists that Debian maintainers go on a war to change Debian's Rust policy to his liking (this is why I left #bcache; I don't set these policies, I'm not interested in fighting against them, and I'm not interested in an infinite rant about how I should spend my energy on such a fight). A couple of other people and myself made some attempts to get the Rust parts of bcachefs-tools buildable and working (and yes, it was really working, and no, the version changes led to no real breakage that I know of), but you can't reasonably package software from an upstream who is so hostile to everything about your distribution. If it's “my way or the highway” about everything, I guess it's the highway, then?

Maybe someone who cares deeply about bcachefs and cares deeply about Debian will pick it up, but that person would better have a really thick skin.

Re: Orphaning bcachefs-tools in Debian

#27

Post by bonzini »

cogman10 wrote: post #18
viraptor wrote: post #5

Earlier quoted context omitted.

This isn't Rust specific. The same issue exists in all languages where the versions can be restricted at project level. It's an issue in Debian because they can't handle multiple concurrent versions (beyond renaming the package) and want every package built without internet access. But that same issue affects Ruby, Python, etc. if the project specifies strict versions. And if you deal with filesystems, you really wan…

It should be noted that, particularly for rust, it's a silly policy as rust does not support dynamic linking of rust libraries. All rust applications are statically linked. So trying to force all projects using foo onto the same version of foo is just a huge headache with no real benefit to anything.

Almost—even if you need to rebuild dependencies, you can still patch security issues just once instead of doing so in every vendored copy. That's the first point in the parent comment.

The same applies to Go.

Re: Orphaning bcachefs-tools in Debian

#28

Post by frankjr »

The list of dependencies doesn't really seem crazy. Logging, parsing command line arguments, band-aiding error traits, working with uuids, reading binary data, "memset_s". All of those should be a part of the standard library as in any other programming language. The fact that you simply cannot build anything but trivial examples without taking a dependency on a third party library is just plain ridiculous and hinders Rust's adoption (as seen in this case). It's especially ridiculous considering Rust positions itself to be used in mission critical systems and yet essentially requires you to implicitly trust hundreds of maintainers for any non trivial project to not be malicious.

https://github.com/koverstreet/bcachefs-tools/blob/b422b19f6...

Re: Orphaning bcachefs-tools in Debian

#29

Post by JackSlateur »

viraptor wrote: post #12
JackSlateur wrote: post #8

Earlier quoted context omitted.

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.

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.

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.

Re: Orphaning bcachefs-tools in Debian

#30

Post by peppermint_gum »

>not even considering some hostile emails that I recently received from the upstream developer or his public rants on lkml and reddit

It feels like whenever the author of bcachefs comes up, it's always because of some drama.

Just the other day he clashed with Linus Torvalds: https://lore.kernel.org/lkml/CAHk-=wj1Oo9-g-yuwWuHQZU8v=VAsB...

My reading is that he's very passionate, so he wants to "move fast and break things" and doesn't get why the others aren't necessarily very happy about it.

Post reply on HN