On Tue, Dec 9, 2025, at 7:05 PM, Ian Jackson wrote:
> Fabian Grünbichler writes ("Bug#1122276: FTBFS: d/control and
> Cargo.toml are not in sync"):
>> Hi!
>
> Hi. Thanks for the report and sorry for the inconvenience.
> I will fix it.
>
>> Either relaxing Cargo.toml to have <0.10 as upper bound, or restricting
>> Cargo.toml and d/control to pick up librust-toml-0.8+default-dev should work.
>> I've attached a patch for the former.
>
> Upstream 1.6.0 has more relaxed dependencies so I am currently trying
> "let's just update" but if that doesn't work I will probably relax the
> dependency.
yes, that one should work
>> Please try to keep Cargo.toml and d/control consistent, or at least
>> d/control more strict than Cargo.toml to avoid breakage like
>> this. debcargo would (in this case, with the upper bound extended to
>> <0.10) generate a Depends on "librust-toml+default-dev (<< 0.10-~~),
>> librust-toml+default-dev (>= 0.5.0-~~)" which would have
>> automatically switched over from 0.8 to 0.9 by virtue of
>> librust-toml-dev not being provided by either librust-toml-0.5-dev
>> nor librust-toml-0.8-dev.
>
> I'm happy to try to avoid similar problems in the future but not sure
> I follow.
happy to expand! :)
> When I uploaded 1.0.1-3, the version currently in stable, toml 0.9
> didn't exist, so the Cargo.toml dependency said "<0.9". (That value
> comes from upstream. The upstream package regularly relaxes its
> dependencies to allow newer versions.)
translating version ranges only works "properly" if they don't cross semver
boundaries, so the correct thing would have been to either
- relax the version constraint to "0.8" in Cargo.toml and
librust-toml-0.8+default-dev in d/control (this would allow switching over
smoothly to packages built from rust-toml-0.8, which we introduced at the
same time as upgrading rust-toml to 0.9, because a lot of upstreams haven't
switched yet)
- relax the version constraint to ">= 0.5, < 0.9" in Cargo.toml and translate
that as "librust-toml+default-dev (<< 0.10-~~), librust-toml+default-dev (>=
0.5.0-~~)" in d/control (which would become unsatisfiable with the upgrade to
0.9, since that is not provided by packages built from rust-toml-0.8, but at
least it is immediately obvious)
- relax the version constraint to ">= 0.5, < 1" in Cargo.toml and translate
that as librust-toml-0+default-dev (>= 0.5.0-~~) in d/control, which of
course breaks in case there is an actually incompatible 0.x release after 0.8
(this is the "crystal ball" option ;))
the "main" librust-foobar-dev package (and all the related versioned provides)
are only ever provided by the unversioned package, because otherwise a version
range crossing semver boundaries would be satisfiable by two packages that are
co-installable while neither of them actually satisfies the version range. this
is a side-effect of cargo supporting version ranges and APT not doing so.
> I presume you don't mean to suggest that I should have, in March,
> before TOML 0.9 existed, preemptively deleted the upstream upper
> dependency requirement ?
we sometimes do that for crates that are still at 0.x and have a high rate of
"technically semver breaking, but breakage mostly not relevant" releases
upstream. I wouldn't say toml is one of those, so IMHO the first option would
have been best. the second one is quite similar to what happened, but moves the
failure already earlier (and easier for tools to detect at least in theory).
I hope this makes it more clear, but I can provide more input if desired!
(also, this kind of breakage is not out of the ordinary for bigger transitions
at all, and I could have spotted it earlier if I would have gone over the
reverse-dependencies with a finer comb - I missed the unversioned package name
in the dependencies in the first place, and as a result assumed everything
would switch over to the semver-suffixed package, which was my fault! I'll
double check the others that haven't popped up yet via debci to ensure they
don't have similar issues.)
Fabian
