Orphaning Bcachefs Tools in Debian

https://jonathancarter.org/2024/08/29/orphaning-bcachefs-tools-in-debian/

by dmm • 2 years ago

5 2 2 years ago

dmm• 2 years ago

So errno, which needed the exact version 0.2, was relaxed so that it could build with version 0.4 in Debian, udev 0.7 was relaxed for 0.8 in Debian, memoffset from 0.8.5 to 0.6.5, paste from 1.0.11 to 1.08 and bindgen from 0.69.9 to 0.66.

This seems to be a common issue packaging newer languages with sophisticated tooling around dependencies. What is the alternative to relaxing deps?

Packaging a dozen version of the same library?

Distributing flatpaks, snaps, containers, etc instead?

pornel• 2 years ago

Packaging a dozen version of the same library?

Cargo uses semver for unifying minor dependency versions, so you don't have dozens versions. It's one per major version. It's not even that different from what Debian does when they package "libfoo5" and "libfoo7". Cargo can have them coexist automatically without renaming, but apt needs this done manually, which creates lots of useless busywork for maintainers who need to map Cargo's requirements to apt's patched forks of Cargo packages.

The real difference is that Cargo unifies versions by upgrading packages to the latest compatible version, and Debian unifies by downgrading to outdated incompatible unsupported junk.

What is the alternative to relaxing deps?

In this case Debian has unforked bindgen, which removed an important patch that the project required:

https://github.com/koverstreet/bcachefs-tools/issues/202#iss...

This doesn't need any sophisticated technology. It needs not futzing with upstream's dependency requirements.

Orphaning Bcachefs Tools in Debian

Related Stories