maribu

Does any rust dev or package maintainer has found a viable approach to downstream patch management? E.g. Arch, Fedora, Alpine and probably most others use diff patches along with the "package recipe", as this allows maintaining everything in one place.

E.g. rust package foo depending on crate bar: If there is a patch for foo, diffs work fine. But what if I need to patch bar? Note that patching in a `[patch.crates-io]` entry is manageable, having that point to a repo is not.

#rustlang #distro

Feb 25 at 5:22amWeb
Show threadmaribuFeb 25

To elaborate on why forking is not maintainable: This would either mean that distros would be forced to scale up their git infrastructure, have to manage access for every new fork of a crate, and have to start to review PRs to those forks with the downstream patches. Or they blindly trust that a contributor's fork is well managed, even if that contributor is on vacation. Or have the patch.crates-io point to a random new fork on every patch update.

Compared to diff patches that adds complexity.

Show threadTamme DittrichFeb 25
@maribu A very naive question as I have no experience with packaging. Would it not be easier to contribute those patches upstream? Or are the changes specific to every distro individually?
Show threadchrysnFeb 25
@tamme @maribu They are typically also provided upstream, but packagers rarely want to wait for upstream to apply and release them.
Pushing them upstream does create a git branch (even a backporting git branch if done directly on the last release tag, though sometimes upstreams don't like having PRs with weeks-old bases), but still creates a reliability issue in that all of a sudden you'd depend on that branch staying reachable (which can go away at any time).
Show threadTamme DittrichFeb 25
@chrysn @maribu ah, yes that makes sense! Thanks for the explanation.
Show threadmaribuFeb 26

I came up with two approaches:

1. cargo would allow an array of patches to be specified in [patch.crates-io] that it will apply to the crate in the specified order

2. a CLI tool that accepts two+ arguments, the name of the crate to patch as first argument and the patch(es) to apply as arguments two etc.: It would then obtain and verify the source as specified in Cargo.toml, apply the patches, and patch the Cargo.toml to use the prepared and patched folder instead.

Show threadmaribuFeb 28

For the problem at hand I ended up doing:

1. Add the release tarball of the dep to the list of sources the package builder downloads and verifies
2. Patch the unpacked dep with the back ported bug fix
3. Patch in an [patch.crates-io] entry into the Cargo.toml to use the patched dep by path
4. Patch the Cargo.lock to match point 3.

That is a bit more involved than I would like, but I think this manageable and maintainable.

Supporting patches directly in [patch.crates-io] would simplify it.

Show threadTamme DittrichFeb 25
@maribu maybe @epage knows an answer to the patch section?
Show threadEd PageFeb 25
@tamme @maribu you can have a Cargo patch point to a directory. Last attempt at patch file support didn't work but we're looking at scaling back its flexibility to see if that will work out.
Show threadMichał FitaFeb 25
@maribu 🤔 how many crates in pure Rust would require patches?
Show threadmaribuFeb 25

@michalfita I cannot really answer that. In Alpine there are currently 661 APKBUILDs that contain the word `cargo`, 221 of those contain `.patch` and in total there are 1017 matches of `.patch` in those 221 packages. Due to the crude method this will be an overestimation, but it strongly suggests that downstream patches for rust packages is not a one-off.

For the problem at hand the issue is in rust source: https://github.com/hoodie/notify-rust/issues/253

panic when closing manually dismissed notification on zbus · Issue #253 · hoodie/notify-rust

According to the docs, a call to CloseNotification returns a dbus error if the notification no longer exists. The dbus implementation just ignores this error notify-rust/src/xdg/dbus_rs.rs Line 97 ...

GitHub
Show threadCalebFeb 26
@maribu patch-based workflows is something I know very little about and I'd guess that's most people - do you happen to have any good links or resources you point someone to when explaining the patch-based workflows, especially for distro maintainers? If you don't have something ready to suggest, no worries. I can go looking.