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

41–50 of 224 posts

Re: Orphaning bcachefs-tools in Debian

#41

Post by yshui »

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 does this, why does Debian has to be different?

Secondly, even if they have to use crates from their repository, I don't understand what's so hard to just have multiple versions of the same crate? That will solve the problem too.

This is just all-around weird what Debian is doing.

(Full disclosure, I am the one who introduced the first piece of Rust code into bcachefs-tools)

Re: Orphaning bcachefs-tools in Debian

#42

Post by [deleted] »

rlpb wrote: post #32
cogman10 wrote: post #18

Earlier quoted context omitted.

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.

> 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 creates a security nightmare. Distributions expect to be able to security patch without waiting for laggard upstreams to bump their pinned dependency versions. If the ecosystem insists that only upstream-sanctioned versions are acceptable, then that runs contrary to this expectation, b…

[deleted]

Re: Orphaning bcachefs-tools in Debian

#43

Post by koverstreet »

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, encryption unlock), playing these kinds of games with swapping dependencies out was not a good idea.

But with Debian and Fedora people alike it's been like talking to a brick wall. "No, your concerns don't matter, this is our policy and we're going to do what we want with your code". They've made it very clear that I have no voice or say in how they package it.

So then he breaks the build by switching to the packaged version of bindgen, an old unsupported version.

And he makes no attempt to debug, doesn't even send me the build error until months later.

As a result, Debian users were stuck on a broken version of -tools that wasn't passing mount options correctly, which meant that when a drive died and they needed to mount in degraded mode, they weren't able to. This happened to multiple people - that bothered to report it. This was quickly fixed upstream, but as far as I know it's still broken in Debian; and Jonathan Carter wasn't fielding any of those bug reports, I was.

I'm tired, frustrated and demoralized by this drama and tired of constantly having to respond to it. This has taken up an enormous amount of my time.

I really wish this guy hadn't packaged -tools for Debian in the first place. I never asked for it. I have enough on my plate to do without a bunch of distro drama to deal with as well.

Re: Orphaning bcachefs-tools in Debian

#44

Post by viraptor »

aragilar wrote: post #34
JonChesterfield wrote: post #13

Earlier quoted context omitted.

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.

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.

Re: Orphaning bcachefs-tools in Debian

#45

Post by AshamedCaptain »

agwa wrote: post #21
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…

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

And that's because the users of Debian are not fine with vendoring.

Re: Orphaning bcachefs-tools in Debian

#46

Post by aragilar »

AshamedCaptain wrote: post #17
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…

In fact, I am tired of the same issue e.g. when evaluating machine learning tools with Python. It's as if everyone just says "dependency = ${exact_version_I_have}" and never considers anything else. Not helped by the fact that most of these projects break ABI every other day which I still think it is just plain evil. Please don't say "just use containers/virtualenvs/vendoring/whatever" because at some point you obvio…

It's 100% culture: this happens across all languages.

Re: Orphaning bcachefs-tools in Debian

#47

Post by IshKebab »

frankjr wrote: post #28

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 hinder…

Nonsense. If these were written in C, and depended on exact versions of getopt, log4c, libuuid, etc and refused to vendor them do you think that would be any easier to package?

This is a result of every Linux distros' self-centred requirement for the entire world to be packaged by them, and a refusal to accept vendoring.

Python has exactly the same problem. You can't even `pip install` on Debian any more because they insist on copying a random selection of Python packages into Apt and they can conflict.

Re: Orphaning bcachefs-tools in Debian

#48

Post by haileys »

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 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.

Re: Orphaning bcachefs-tools in Debian

#49

Post by [deleted] »

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.

[deleted]

Re: Orphaning bcachefs-tools in Debian

#50

Post by Brian_K_White »

The same bcachefs that Linus just ripped apart for inconsiderate and irresponsible PRs?

Sensing a pattern and it's not both Debian and the kernel. I mean can you even point at 2 more proven solid large and long term projects that have proven how to do it right?

Post reply on HN