On Tue, Dec 9, 2025, at 7:54 PM, Ian Jackson wrote:
> Fabian Grünbichler writes ("Re: Bug#1122276: FTBFS: d/control and
> Cargo.toml are not in sync"):
>> On Tue, Dec 9, 2025, at 7:05 PM, Ian Jackson wrote:
>> > 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
>
> I'm not sure if you are are suggesting things I could have done in
> March. I think the only one of these suggestions I could sensibly
> have done in March is this one:
I think you could have also done a variant of 1) that only tightens
the dependency in d/control. But yes, that would also require manual
work and would only happen to have worked in this case, because the
highest version satisfying the upstream version was the version
packaged at the time in unstable, which is not a given in general ;)
>> - 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 ;))
>
> Right. I don't think that's obviously unreasonable. It would have
> prevented this FTBFS. As you may know, I think this might be a good
> idea to do in Debian more widely.
It's always possible to do this (manually atm), it is a tradeoff
between risking breakage not caught at the package metadata level vs.
additional work for transitions doing "version bump/relaxation only"
uploads.
> But we don't have tooling to do this automatically. As a result, if I
> did this downstream in Debian, I would have a bureaucratic metadata
> conflict to resolve at every upstream update where the same dependency
> is made explicit but also explicitly relaxed. So that's why I didn't
> do that.
Yes, this variant is also not without downsides. There (unfortunately)
is no free cake here :(
>> (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.)
>
> Right.
>
> Anyway, after I fixed a foolish hardcoding in my rules file, 1.6.0
> works great. I have just upload it.
>
> I also added a README.source which I hope will help folks in the
> future - especially, I hope that if for some reason I'm not available
> promptly, it would give the Debian Rust Team several good optiosn for
> getting unblocked.
Thanks for the speedy reaction!
> https://browse.dgit.debian.org/rust-derive-deftly.git/tree/debian/README.source
And also thanks for this - I will try to remember it for the next time :)
