3:41 a.m.
On Tue, Aug 9, 2022 at 5:04 AM Orion Poplawski <orion(a)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