Orphaning bcachefs-tools in Debian • Hacker News Board

Re: Orphaning bcachefs-tools in Debian

#171

Post by randombloke » Sat, Aug 31, 2024, 6:45 PM UTC

complaintdept wrote: post #146

ants_everywhere wrote: post #89

Earlier quoted context omitted.

Hey at least it's not the worst behavior we've seen from a Linux file system creator... I thought Carl Thompson's response was very good and constructive: https://lore.kernel.org/lkml/1816164937.417.1724473375169@ma... What I don't understand is that IIUC Kent has his development git history well broken up into small tight commits. But he seems to be sending the Linux maintainers patches that are much larger than the…

> Hey at least it's not the worst behavior we've seen from a Linux file system creator... I think that dubious distinction would go to Hans Reiser.

[flagged]

Re: Orphaning bcachefs-tools in Debian

#172

Post by tsimionescu » Sat, Aug 31, 2024, 6:50 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…

Because Debian and similar distros have a goal of maintaining all of the software that users are expected to use. And this means they commit to fixing security issues in every single piece of software they distribute.

A consequence of this is that they need to fix security issues in every library version that any application they distribute uses, including any statically-linked library. So, if they allow 30 applications to each have their own version of the same library, even Rust crates, and those versions all have a security issue, then the Debian team needs to find or patch themselves 30 different pieces of code. If instead they make sure that all 30 of those applications use the same version of a Rust crate, then they only need to patch one version. Maybe it's not 30 times less work, but it's definitely 10 times work. At the size of the Debian repos, this is an extremely significant difference.

Now, it could be that this commitment from Debian is foolish and should be done away with. I certainly don't think my OS vendor should be the one that maintains all the apps I use - I don't even understand the attraction of that. I do want the OS maintainer to handle the packaging of the base system components, and patch those as needed for every supported version and so on - and so I understand this requirement for them. And I would view bcachefs-tools as a base system component, so this requirement seems sane for it.

Re: Orphaning bcachefs-tools in Debian

#173

Post by AshamedCaptain » Sat, Aug 31, 2024, 6:51 PM UTC

ris wrote: post #167

AshamedCaptain wrote: post #17

Earlier quoted context omitted.

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 as if everyone just says "dependency = ${exact_version_I_have}" and never considers anything else. This is what I call "version soup". The idea that every project can choose an near-arbitrary set of very exact version numbers of dependencies and expect it to work. And that every project on earth has the burden of continually stirring their soup, often through a tool like dependabot, hoping (cross fingers) no c…

> In nixpkgs we attempt to address this situation for the python ecosystem by providing one version of each package (with few exceptions) per release. But in return, we put in work to make sure those versions actually work with each other - generally by getting the projects' test suites integrated into the build system. The idea is that an app built to depend on nixpkgs packages should be able to expect to do dependency upgrades as a "jump" every 6 months when there's a new nixpkgs release, but otherwise be able to depend on a stable suite of packages that still receives security updates & backports.

Is this different from any other Linux distribution?

Re: Orphaning bcachefs-tools in Debian

#174

Post by tsimionescu » Sat, Aug 31, 2024, 6:59 PM UTC

cogman10 wrote: post #40

rlpb wrote: post #32

Earlier quoted context omitted.

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

Fair point. I do think we need to reevaluate how security is managed in terms of software. It's often the case that we say "this library version has a CVE, we need to update it!" However, it's not often the case that the CVE in the library is even exploitable from the parent application. I'm thinking of a recent 9 CVE against zlib... But actually it was a rarely used extension API for working with compressed files. S…

I think it's already complicated to find all the software that uses a library version that has a known vulnerability, because of the many slightly different versions floating around, static linking, software running in docker containers etc. Expecting to further identify which applications use a particular part of a library gets even more difficult, and lazy developers will use this as an excuse not to patch far more often than you'll save on unnecessary updates.

Not to mention, this already happens to some extent, especially for older versions of software: distributors and developers do sometimes say "we will not provide a patch because even if we use the affected library, we don't use it in a way that triggers the vulnerability".

Re: Orphaning bcachefs-tools in Debian

#175

Post by andrewshadura » Sat, Aug 31, 2024, 7:07 PM UTC

mahkoh wrote: post #97

smashed wrote: post #81

Earlier quoted context omitted.

> I would rather something not be packaged at all than packaged badly; this whole experience reads like a lesson in what not to do. You might consider adding a big warning on your official documentation about unsupported distribution packages. Add links to relevant issue tracker/bug reports or mailing list discussions saying until So and so issue are resolved, the official statement is that distribution package is un…

0.2 and 0.4 are different "major releases" of rust crates as you say. The major release is determined by the first non-0 component in the version number. The issue is that debian appears to only allow one version even if there are multiple major versions. If debian is fine with packaging versions 2.0 and 4.0 but not 0.2 and 0.4, then debian does not understand rust version numbers.

Debian allows this. However, it's extra work for package maintainers and extra headache on the security front.

Re: Orphaning bcachefs-tools in Debian

#176

Post by phlip9 » Sat, Aug 31, 2024, 7:22 PM UTC

rlpb wrote: post #14

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…

Maintenance is much more practical if everything in your dependency tree uses the same version of every dependency. Achieving this in practice is much of the work distribution maintainers have to do. Doing this has a couple of key advantages: 1. when a security vulnerability needs patching in a stable distribution release, the security team only have to patch one version instead of a dozen or more different versions…

Maintenance is much more practical when you use the versions upstream tests in their CI and not whatever mishmash of ancient/silently incompatible deps that each distro separately decides to combine together.

Re: Orphaning bcachefs-tools in Debian

#177

Post by eqvinox » Sat, Aug 31, 2024, 7:26 PM UTC

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…

> this whole experience reads like a lesson in what not to do.

What lessons have you drawn from it?

Re: Orphaning bcachefs-tools in Debian

#178

Post by 1oooqooq » Sat, Aug 31, 2024, 7:28 PM UTC

mananaysiempre wrote: post #31

1oooqooq wrote: post #15

Earlier quoted context omitted.

exactly. the sad part is that this is being coopted into an aegument for flatpack! it's insane the discussions on some distros. they cannot see that by giving in to static libs you make every little application maintainer into a full-time distro maintainer responsible for it forever. ... good luck with that.

I actually don’t entirely agree with Górny’s argument that we should use the technical tool of shared libraries to solve the social problem of not organizing the package archive in a way that allows an automatic bump of every dependency on a static library change. But I do agree with a weakened version where “static libraries” is replaced with “vendored code”, and that’s the (part of) problem TFA describes. (The rest…

I'm also on (several) the fence on the solution. but the description of the problem is spot on

Re: Orphaning bcachefs-tools in Debian

#179

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

pessimizer wrote: post #117

curt15 wrote: post #61

Earlier quoted context omitted.

What makes a system engineering language "proper"? And what languages besides C fulfill those criteria?

The grammar might be confusing, but the comment you're replying to clearly considers rust a (new) proper systems language, and nicer in many ways (memory management and overall ergonomics) than C, but with worse (from the perspective of systems programming) tooling.

thanks for making it more succinct. exactly.

Re: Orphaning bcachefs-tools in Debian

#180

Post by steve-rambo-fan » Sat, Aug 31, 2024, 7:30 PM UTC

boris wrote: post #131

koverstreet wrote: post #74

Earlier quoted context omitted.

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

[flagged]

The only "junk" I'm seeing here is your comment. If you don't find bcachefs interesting, please move along and keep your bitter thoughts to yourself. Last thing we need is more assholes harassing Kent into throwing in the towel on the best GPL-compatible alternative to ZFS we're likely to have in decades.