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

201–210 of 224 posts

Re: Orphaning bcachefs-tools in Debian

#201

Post by aragilar »

2OEH8eoCRo0 wrote: post #161
megous wrote: post #158

Earlier quoted context omitted.

Not in the kernel land. Stable branches feature tens of thousands of patches.

Patches are expected but the kernel interfaces shouldn't change right? Like if I write a kernel module no patch should break my compatibility and make my module not build anymore (I think)? I don't care if it changes underneath as long as it doesn't change where I interface.

Userspace doesn't break, but if you don't want your module to break, upstream it (which is an important lesson about hardware selection: if it's not upstream and not being upstreamed, then you're going to get stuck on an old kernel at some point).

ZFS has broken on new releases (I don't recall if they were stable, I think they were), and that is one reason I won't use as the main filesystem on linux.

Re: Orphaning bcachefs-tools in Debian

#202

Post by aragilar »

epage wrote: post #124
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…

In Rust, it is frowned upon to pin to an exact version. We do encourage people to specify what semver version range will work. We don't have great support for depending on and verifying multiple-major version ranges when a library broke compatibility but not in a way that affects you.

Is this being tracked somewhere?

Re: Orphaning bcachefs-tools in Debian

#203

Post by rixed »

ants_everywhere wrote: post #89
peppermint_gum wrote: post #30

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

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…

It's not about the size of each individual patches but about the large amount of changes in total *during the freeze•.

Re: Orphaning bcachefs-tools in Debian

#204

Post by jmb99 »

CJefferson wrote: post #35
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…

Where are those things in the standard library of C or C++, which most software is written in? Most C Debian packages have a few dependencies in my experience, they are just “standard”, because they are old and stable.

Parsing command line arguments, reading/manipulating binary data, memset_s are of course all available in the C standard library. I’m not familiar with rust, but if it’s true that dependencies are required for those types of basic operations... yikes, to say the least. If you include boost (which, admittedly, is a heavy dependency, but still a single one), everything mentioned is possible.

Re: Orphaning bcachefs-tools in Debian

#205

Post by steveklabnik »

jmb99 wrote: post #204
CJefferson wrote: post #35

Earlier quoted context omitted.

Where are those things in the standard library of C or C++, which most software is written in? Most C Debian packages have a few dependencies in my experience, they are just “standard”, because they are old and stable.

Parsing command line arguments, reading/manipulating binary data, memset_s are of course all available in the C standard library. I’m not familiar with rust, but if it’s true that dependencies are required for those types of basic operations... yikes, to say the least. If you include boost (which, admittedly, is a heavy dependency, but still a single one), everything mentioned is possible.

Just to be clear about it, Rust has the same level of this stuff in the standard library as C does. Like, the equivalent of argc/argv is in the rust standard library. The library being included is more like getopt conceptually; a package built on top of that that makes things nicer.

Re: Orphaning bcachefs-tools in Debian

#206

Post by IshKebab »

haileys wrote: post #10
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…

I think this is the same shape of issue that I’ve experienced with Debian for as long as I’ve used it - close to 15 years now. Debian is a great OS, but it targets stability and long term support for its releases. That just isn’t compatible with newer, faster moving software that’s still working towards stability. I remember it being an issue when I was playing around with Mono around 2010 ish, and it’s an issue now…

I agree. Debian is a waterfall OS living in an agile world. There's a fundamental mismatch between Debian's philosophy and the reality of today's open source software ecosystem.

Re: Orphaning bcachefs-tools in Debian

#207

Post by IshKebab »

brnt wrote: post #96
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…

> What Debian and Fedora have been doing is a big step backwards, this whole 'unbundling of dependencies' (that were going to be statically linked anyways) needs to die. They, and most others, have been doing that since their respectively beginnings, and for good reasons: everybody expects distros to fix security issues, which is greatly aided by ensuring an-as-small-as-necesary dep tree and thus a single version of…

> everybody expects distros to fix security issues

IMO this is a huge mistake in the Linux distro world. It doesn't scale. It's similar to the weird idea that Debian should contain every program in the world and if the authors want their programs to be installable on Debian they must make a Debian package for it. And Fedora and Arch and Gentoo and...

Clearly bonkers.

Re: Orphaning bcachefs-tools in Debian

#209

Post by kijin »

zamadatix wrote: post #160
kijin wrote: post #115

Earlier quoted context omitted.

> There's also the issue that having multiple versions means maintaining multiple versions (applying security fixes and so on). This is the most important part. Debian LTS maintains packages for 5 years. Canonical takes Debian sources, and offers to maintain their LTS for 10 years. Red Hat also promises 10 years of support. They don't want anything in the core part of their stable branches that they can't promise to…

I didn't get the impression anyone bothered the maintainers to do this, the article implies they chose to package it on their own accord.

Yes, and they chose to stop packaging it, again on their own accord.

Except this time, they seem to have made the decision because upstream was bothering them too much.

Re: Orphaning bcachefs-tools in Debian

#210

Post by rcxdude »

rlpb wrote: post #197
rcxdude wrote: post #195

Earlier quoted context omitted.

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.

It can work perfectly well, at least as far as API/ABI compatibility. An app is an executable, a library is a static or dynamic library. Something isn't generally both at once (a project or package might have a library and some tool applications related to the library, but those tend to get split out by distribution package maintainers anyway, and with cargo there's always a top-level package which sets the pinning, the rest are libraries whether or not they're the top level in other contexts). If you're talking about IPC or RPC, then yes, this matters more in terms of compatibility, but that's an area where a lot more attention is paid to compatibility in the first place, by everyone.
Post reply on HN