On Tue, Aug 9, 2022 at 5:04 AM Orion Poplawski orion@nwra.com wrote:

So, how does one actually go about updating a rust package? How do you find out what breaks with the update?

Rust uses semantic versioning (with one small difference from the upstream spec). So updating a crate from version 1.x to 1.y should always be fine. Updating a crate from version 0.1.x to 0.1.y is also fine. But updates from 1.x to 2.y, or updates from 0.x to 0.y, are problematic, because dependent packages will usually depend on them like BuildRequires: (crate(foo) >= 0.1.0 with crate(foo) < 0.2.0).

As a rule of thumb: For post-1.0 releases, updating a version 1.x to 1.y (or 2.x -> 2.y, etc.) is fine. For pre-1.0 releases, updating a version 0.1.x to 0.1.y (or 0.2.x -> 0.2.y, etc.) is fine, since those release branches claim to only include backwards compatible changes.

Do we always provide a compat package, or do we try to update the deps? Go for it in a side tag and make a compat package if we can't update the deps?

It depends on three factors: - how many packages depend on the old crate version, - how big are API changes between the versions, - how much time I have to deal with the situation

For example, looking at updating miniz_oxide to 0.5.3, if I try to install on my devel machine that is loading with rust packages I get:

Please, don't do that. Rust packages are not designed to be installed outside temporary mock chroots. Build with mock instead, if at all possible. For example, we don't set up any Obsoletes for removed subpackages, and there is no guaranteed upgrade path, especially when we need to create compat packages. So *if* you install rust-*-devel packages on your host machine, you will pretty regularly get upgrade issues. You'll also need to continuously refresh BuildRequires with those generated by the crates that you want to build, which is a huge hassle if you can't let mock handle this automatically for you.

But I don't know how to construct a repoquery that would test for that.

You can use this bash script to check for impact when pushing breaking versions: https://github.com/decathorpe/miscripts/blob/master/cratedeps

Like this:

$ cratedeps miniz_oxide

And it will list all source and binary packages that depend on the current version of miniz_oxide:

rust-backtrace-0:0.3.64-2.fc37.src rust-backtrace-devel-0:0.3.64-2.fc37.noarch rust-flate2-0:1.0.22-3.fc37.src rust-flate2+miniz_oxide-devel-0:1.0.22-3.fc37.noarch rust-miniz_oxide+default-devel-0:0.4.4-4.fc37.noarch rust-miniz_oxide+no_extern_crate_alloc-devel-0:0.4.4-4.fc37.noarch rust-png-0:0.17.2-2.fc37.src rust-png-devel-0:0.17.2-2.fc37.noarch rust-tiff-0:0.6.1-5.fc37.src rust-tiff-devel-0:0.6.1-5.fc37.noarch

This means:

- rust-backtrace depends on miniz_oxide v0.4 at build- and at install-time (though a pending update already requires miniz_oxide 0.5) - rust-flate2 depends on miniz_oxide v0.4 at build- and at install-time (though a pending update already requires miniz_oxide 0.5) - rust-png depends on miniz_oxide v0.4 at build- and at install-time (though a pending update already requires miniz_oxide 0.5) - rust-tiff depends on miniz_oxide v0.4 at build- and at install-time (the pending update to v0.7 drops the dependency on miniz_oxide, but we still need v0.6)

The updates for the "backtrace" crate are always a bit tedious, because it requires a coordinated update of backtrace, addr2line, object, and other crates. I will tackle that in the near future.

Looking at the changelog for miniz_oxide, it doesn't seem that there were badly breaking API changes with 0.5: https://github.com/Frommi/miniz_oxide/blob/master/CHANGELOG.md

So it might be possible to port current users of miniz_oxide to version 0.5 without too much work, but I'd like to avoid pushing two updates for backtrace, so I'd rather include it in the update, as well. So, taking all this into account, this is what I will probably do:

- update miniz_oxide to v0.5 - update backtrace to the latest version (including addr2line, object, etc.) - update flate2 to latest version - update png to latest version - attempt to port tiff v0.6 to miniz_oxide 0.7 - add a compat package for miniz_oxide 0.4 if porting tiff to v0.5 fails

Fabio