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

191–200 of 224 posts

Re: Orphaning bcachefs-tools in Debian

#191

Post by 3np »

koverstreet wrote: post #100
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…

Honesty, I think I just presented that pull request badly. I included the rcu_pending and vfs inode rhashtable conversion because I was getting user reports that it fixed issues that were seriously affecting system usability, and because they were algorithmically simple and well tested. Back in the day, on multiple occasions Linus and others were rewriting core mm code in RC kernels; bcachefs is still experimental, s…

> bcachefs is still experimental, so stuff like this should still be somewhat expected.

I really think you need to realign your expectations here. The Linux kernel is in a different place now than "back in the day" and you are not Linus Torvalds.

That PR would have been better off had it been split into multiple ones and timed differently.

Re: Orphaning bcachefs-tools in Debian

#192

Post by cozzyd »

chungy wrote: post #145
jonathanspw wrote: post #133

Earlier quoted context omitted.

AlmaLinux has made no such statement, for what it's worth.

Red Hat Enterprise Linux excludes btrfs support in its distribution because Red Hat does not believe btrfs to be stable enough to be worth considering. That decision trickles down to recompilation projects that pretty much amount to "RHEL, but without having to pay for it".

And rightfully so, imo. btrfs is the only filesystem I've used where it's gotten so corrupted due to faulty memory on a computer that I had to recover the files and reinstall from scratch after replacing the memory (obviously not using btrfs the second time ..).

Re: Orphaning bcachefs-tools in Debian

#194

Post by est31 »

sp1rit wrote: post #78
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…

Still, if you include transitive dependencies you end up with a total of 90 dependencies[0] which is unheard of in systems programming. This for some reason includes stuff like "winapi-i686-pc-windows-gnu" which really has no place for a set of linux software tools. [0]: https://github.com/gentoo/gentoo/blob/master/sys-fs/bcachefs...

The winapi dependency comes from the rust tooling (cargo specifically) putting a great value on portability, and practical concerns like people collaborating from different platforms on the same project. Many Rust projects check their Cargo.lock into git (recommended for binaries, and also many libraries do it). Now imagine if the Cargo.lock changes depending on the platform, which one would you track in git?

Now, there is the separate concern of cargo-vendor downloading the winapi crate, which it does, also on Linux. It doesn't have to because winapi is never built, yet it still does it. That one I agree is a bit wasteful, but it's a known issue.

Re: Orphaning bcachefs-tools in Debian

#195

Post by rcxdude »

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…

Generally speaking libraries don't pin versions, applications do (in rust-land, a Cargo.lock is respected for the folder you're building, not your dependencies. A dependency can specify an exact version if it wants but an application can override that kind of thing, and it's generally not considered a good idea). This makes 2) a non-issue for the ecosystem (if an application needs to pass objects from X between A and B, then they'll need to pin to a single version of X). 1) is more of a disadvantage, but it's unclear to me that the effort distro maintainers put in to fix to a single version actually results in a reduction in effort overall.

Re: Orphaning bcachefs-tools in Debian

#196

Post by Arch-TK »

ralferoo wrote: post #189
Arch-TK wrote: post #169

Earlier quoted context omitted.

> enlighten me Fundamentally on the whole I don't think most of your interpretation is comment worthy. (To clarify, I don't think its particularly objectionable following from the premise in your opening paragraph.) But... > in the stable branch timeline Again. Like I outlined in my initial reply. This has nothing to do with stable. I don't know why you keep talking about stable. The discussion is about bleeding edge…

> So, your comment is based on the premise of this being a discussion surrounding stable. It's not, so I don't know what to make of the rest of your comment on the basis of this incorrect premise. The repo is literally called "linux-stable-rc" It wasn't an incorrect premise, just incorrect terminology. Sorry, my bad, I shouldn't have referred to it prematurely as "stable" when it is just undergoing the process of sta…

> The repo is literally called "linux-stable-rc"

It's not? What repo? The only two repos which are involved are https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin... which is mainline (implicitly) which is where these patches would land and git://evilpiepirate.org/bcachefs.git which is the source repo for the PR. The only branches being referenced are "master" (implicitly) for mainline and the tag "bcachefs-2024-08-23".

Regardless, to respond to the rest of your comment:

The reasons for why Linus is rejecting the change have nothing to do with the stable process and everything to do with the set release process. The mainline merge window opens, you (not you specifically unless you are a subsystem maintainer, if you want to contribute a patch as a non-maintainer, the process is completely separate and goes via the subsystem maintainers) submit features and bug fixes, the merge window closes, somewhere in the ballpark of 7 release candidates happen, and it's released as mainline. The goal of the RCs is to incorporate subsequent waves of fixes for any regressions introduced specifically by the bug fixes and new features.

Kent is claiming that, because he himself implements effectively an equivalently rigorous (according to him) feature testing and stabilisation process that his patches which do not fix regressions introduced by previous patches submitted during the merge window, but which do fix some real bugs, should be accepted outside the merge window.

In the past, Linus has let it slide, and he has also let it slide this time too: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin... . Linus is just asking Kent to stop doing this as he doesn't want to keep giving him special treatment.

Re: Orphaning bcachefs-tools in Debian

#197

Post by rlpb »

rcxdude wrote: post #195
rlpb wrote: post #14

Earlier quoted context omitted.

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…

Generally speaking libraries don't pin versions, applications do (in rust-land, a Cargo.lock is respected for the folder you're building, not your dependencies. A dependency can specify an exact version if it wants but an application can override that kind of thing, and it's generally not considered a good idea). This makes 2) a non-issue for the ecosystem (if an application needs to pass objects from X between A and…

One package's app is another package's dependency, so this distinction cannot work in the general case.

Re: Orphaning bcachefs-tools in Debian

#198

Post by ralferoo »

Arch-TK wrote: post #196
ralferoo wrote: post #189

Earlier quoted context omitted.

> So, your comment is based on the premise of this being a discussion surrounding stable. It's not, so I don't know what to make of the rest of your comment on the basis of this incorrect premise. The repo is literally called "linux-stable-rc" It wasn't an incorrect premise, just incorrect terminology. Sorry, my bad, I shouldn't have referred to it prematurely as "stable" when it is just undergoing the process of sta…

> The repo is literally called "linux-stable-rc" It's not? What repo? The only two repos which are involved are https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin... which is mainline (implicitly) which is where these patches would land and git://evilpiepirate.org/bcachefs.git which is the source repo for the PR. The only branches being referenced are "master" (implicitly) for mainline and the tag "bcachefs…

> It's not? What repo?

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux...

Re: Orphaning bcachefs-tools in Debian

#199

Post by koverstreet »

sangnoir wrote: post #186
qalmakka wrote: post #155

Earlier quoted context omitted.

> The guy even admits it as well with his repeated "please don't actually use this in production" style messages - it's hard to give a greater indication than this that the code isn't yet ready for stable. True that, and yet the kernel has zero issues keeping Btrfs around even though it's been eating people data since 2010. Kent Overstreet sure is naive at times, but I just can't not sneer at the irony that an experi…

> True that, and yet the kernel has zero issues keeping Btrfs around even though it's been eating people data since I can imagine scenarios where known failure modes on an "inferior" tool are better than unknown failure modes on a "superior" one.

honestly, it's mostly just a matter of trying to give myself the time to work with bugs as people hit them, and stage the rollout. I don't want clueless newbies running it until it's completely bulletproof.

Re: Orphaning bcachefs-tools in Debian

#200

Post by aragilar »

SkiFire13 wrote: post #136
aragilar wrote: post #20

Earlier quoted context omitted.

What I think is somewhat interesting in this case (if I've read the post correctly) half the changes were for newer versions of dependencies. If that's the case, then I'm inclined to start wondering what's going on with bcachefs upstream (and the whole dependency tree), if they're not keeping up with versions.

Imagine that an update of bcache-fs is released and 3 dependencies (could even be transitive) were updated and the newer versions were not packaged in Debian. The maintainer now has one package to update but another 3 to package for the first time. That's additional work. AFAIK Fedora has a tool to automatize this work, but maybe Debian has additional requirements that make this harder.

Debian (and derivs) have similar tooling (and the vast majority of rust packages are tracked in a monorepo https://salsa.debian.org/rust-team/debcargo-conf).

My point was "some of the upstream versions were older than Debian's" which means the "Debian is behind, Debian is slow" is not true in the case. That usually only happens where an upstream is either very conservative with bumping versions, or where upstream is under-maintained, neither which at first glance seem to be true of becache-fs.

Post reply on HN