On 28/04/2023 06:05, Helmut Grohne wrote:
Can you go into more detail as to what you mean with "don't support
version ranges"?
You can place a lower bound on the version, place an upper bound
on the version or constrain to a precise version. But you can't
constrain to a range of versions.
In principle, you could declare the Replacs to be
slightly broader than necessary (i.e. instead of declaring against the
specific range, you can replace all old packages). Do you agree that
this is feasible?
It would indeed be feasible to continue declaring the breaks
against the virtual package, while declaring the replaces
against the physical package.
My only concern is this may bring in bug reports complaining
about a replaces without a matching breaks. Tehcnically I
don't see anything in policy actually forbidding such but
it goes against the norm.
5. In a different bug, Samuel Thibault observed that the target package
was not part of bullseye. As such, an upgrade scenario involving it
was unlikely. All of the 6 affected librus-*-dev packages are not
part of bullseye. We could argue that the risk of these effects
showing up in practice is not big enough to warrant an invasive fix.
Rather, we'd downgrade them to important (and upgrade to serious
when we see them in the wild) and close them after bookworm (since
we don't support skip upgrades).
While the target packages aren't part of bullseye, they could well end up pulled
in as part of an upgrade, since the purpose of these packages is to continue
providing older versions of a crate when the main package of the crate is
upgraded.
It then comes down to unpack order, if the package manager unpacks the upgrade
before the new package then all is cool. OTOH if the new package is unpacked
first you would have a conflict.
What I don't know is how real-world package managers handle installation
order and thus how likely seeing the "bad" ordering is in practice.
The issue won't go away after bookworm. These particular packages won't be
affected for a bookworm->trixie upgrade but future packages almost certainly
will be.
On the other hand these are packages that are mostly used as
build-dependencies and are rarely installed on end-user systems.
Do any other members of the rust team have an opinion on this? I'm
personally inclined towards option 1 and intend to implement it if
noone objects in the next couple of days.
Let me know if you see 4 as a viable option.
I would say it's viable.
Do the release team have an opinion on this? It looks like only one of
the packages involved (rust-env-logger-0.7) is a key package.
I filed these as serious, because these are policy violations with a
trivial fix. You made it quite clear that the premise of the fix being
trivial is false here. If the cure is worse than the symptoms
I don't think the cure is worse than the symptoms.
