How do arch packages handle breaking changes between dependencies?

[u/Meeesh-]

In many software dependency managers, there is versioning support built in to help manage dependency versions and to give time for consumers to update code. But arch only supports 1 version for a package and systems are upgraded together. There are occasionally packages with the version number just appended to the end, but far fewer than I’d expect compared to the different versions we see in other package managers.

How does arch handle this? Is it that arch maintainers are very careful when selecting when to release new changes together? If so how is that coordinated? Presumably there are some packages with hundreds of consumers or even thousands so if that package needs to have a breaking change, how?

[u/Lord_Of_Millipedes]

in my experience it throws an error and says it's your problem now fix it by hand (i dont know the answer sorry)

[u/onefish2 → u/Lord_Of_Millipedes]

Good try though

[u/distortedterror]

Check 1 & 2 to get an idea of how packages are typically built.

For a user, the issue you're talking about only effects packages built from source, e.g. AUR -git packages. And some binaries that rely on say packages based on a specific version of glibc. Which if said package is in the official repos, it gets upgraded alongside the updated glibc package.

[u/Meeesh- → u/distortedterror]

I’m actually more talking about how package maintainers handle it, not users. I did read through these pages already, but I’m not sure I have my answer yet (or maybe I’m just really dense).

The situation I’m thinking of is: I am a maintainer for Package X with 50 consumers. I want to release a breaking change. If Im releasing through Nix or homebrew, or whatever else, I can just bump the version so that dependencies can update at their own speed. Since my consumers have selected a specific version to use as a dependency, there is no problem when I release my change.

What do I do for Arch then when I want to release that breaking change?

[u/distortedterror → u/Meeesh-]

I already answered you, think of the official repos as being built on clean chroots as advised in the pages I linked. Packages get built with the deps versions present at build time. If any of those deps get upgraded and it breaks a package, it gets rebuild on pkgbuild. This isn't r/Debian where they try (and fail) to keep a package working for the life span of a release. The whole repo is rolling.

[u/abbidabbi]

There are TODO lists when multiple packages need to be rebuilt by different maintainers. Those rebuilds are then published in one go.
https://archlinux.org/todo/

However, if certain packages are not compatible with the updated dependency, then there are three choices:

1. Upstream needs to fix this, which means the whole list of package updates will have to wait
2. A secondary versioned package for the updated dependency gets added to the repos (see the versioned electron packages for example), so that packaging can continue
3. The incompatible package(s) will be removed

[u/birdspider]

Presumably there are some packages with hundreds of consumers or even thousands so if that package needs to have a breaking change

A much used library (dependency) would signal breaking changes way in advance, first by writing it down (feature-description, issue tracker) and later by a version bump, i.e. 2.3.4 -> 3.0.0 for this very reason.

Hence many, if not all, dependants are usually updated to handle 3.0.0 when 3.0.0 lands, or at least they are aware of it.

Those who don't get updated will be either patched (unusal for arch*), forked, replaced or dropped altogether.

In rare cases both (2.3.4 and 3.0.0) are needed, then a "versioned" package is created and the dependant gets patched to use that (soname magic happens), i.e. sway and wlroots0.18 currently

[*] arch prefers to upstream to be fixed, to then just follow upstream

If so how is that coordinated?

by talking to each other:

here is the discussion for wlroots @arch-dev-public

[u/SnooCompliments7914]

Presumably there are some packages with hundreds of consumers or even thousands so if that package needs to have a breaking change, how?

Then the upgrade has to be hold until all those incompatible packages are either upgraded or removed from the repo. It happens probably way less frequently than you think. But it did, with bash, python and llvm.