[Pkg-rust-maintainers] Bug#1054156: Bug#1054156: librust-env-logger-0.7+default-dev shouldn't provide librust-env-logger+default-dev

[Fabian Grünbichler]

On Fri, Oct 27, 2023 at 07:55:07PM +0300, Adrian Bunk wrote:
> On Fri, Oct 27, 2023 at 05:07:12PM +0200, Fabian Grünbichler wrote:
> > On Wed, Oct 18, 2023 at 02:06:48PM +0300, Adrian Bunk wrote:
> > > Package: librust-env-logger-0.7+default-dev
> > > Severity: serious
> > > 
> > > https://buildd.debian.org/status/fetch.php?pkg=mdevctl&arch=arm64&ver=1.2.0-4%2Bb3&stamp=1697626199&raw=0
> > > 
> > > ...
> > > Merged Build-Depends: ..., librust-env-logger+default-dev,
> > > ...
> > > The following NEW packages will be installed:
> > > ...
> > >   librust-env-logger-0.7+default-dev librust-env-logger-0.7-dev
> > > ...
> > > error: failed to select a version for the requirement `env_logger = "^0.10.0"`
> > > ...
> > > 
> > > 
> > > This is due to:
> > >   librust-env-logger+default-dev reverse Provides:
> > >   librust-env-logger-0.7+default-dev 0.7.1-4 (= 0.7.1-4)
> > >   librust-env-logger-dev 0.10.0-2 (= 0.10.0-2)
> > > 
> > > 
> > > I'll file a separate bug for mdevctl having a too loose build dependency.
> > 
> > I am not sure why it shouldn't? librust-env-logger-0.7-dev does contain
> > env_logger source code after all
> >...
> 
> Having two in the archive makes it unpredictable which version the 
> dependency solver uses when building a reverse dependency.

yes. with the caveat listed below that having such a dep in the first
place is non-standard.

> Different architectures might end up being built with different versions.

that's always true though since nothing forces builds on different archs
to use the same set of packages?

> A binNMU might change the version used, even switching from 0.10 to 0.7.

yes. if the rdep is compatible with both versions, is that a problem?
and this is also the case in general, a binNMU is not different than
other builds in this regard, right?

> rust-env-logger-0.7 (0.7.1-3) unstable; urgency=medium
>   * Release as versioned package for other rdeps that can't update to 0.9
> 
> This should really only be used after an explicit opt-in.

it is. having an unversioned dependency is one way to say "I am fine
with getting a version that might not be the most recent". the other is
depending on (in this case) librust-env-logger-0.7-dev (or a variant
thereof), which might be built by src:rust-env-logger (in version
0.7.X-Y) or by src:rust-env-logger-0.7 (in version 0.7.X-Y).

the non-versioned variant should only be used if you want to build with
a possible range of versions and don't care which one you get. the
default behaviour (at least in Rust packaging) is to depend on the
semver-prefix-containing variant, which entails exactly the behaviour
you want, except for a possible short period of time where
src:rust-env-logger in the newer version might not have hit the archive
yet, but src:rust-env-logger-0.7 already has. in that case, the two
should be functionally identical though, so it matters even less which
one gets picked ;)

> 
> >...
> > depending on just librust-env-logger+default-dev without a
> > version constraint says "I want env_logger with the default feature(s),
> > but don't care about the version" - which in almost all cases isn't
> > sensible.
> >...
> 
> 
> There are packages with
>   Build-Depends: librust-env-logger+default-dev (>= 0.9)
> in the archive, if these were >= 0.7 it would be the same problem.

yes, but if they were >= 0.7 they should be fine with 0.7? and if the
new src:rust-env-logger (in version > 0.7) doesn't build yet on an arch,
or is still waiting for some dependency to become available, or .. then
changing the semver suffix package to not provide librust-env-logger-dev
would break those rdeps, since they become unsatisfiable? or, if the old
version is still around binary-wise, the builds might pick up different
versions anyway on different architectures..

the only reason those semver-suffix packages even exist in the first
place is to allow
- seamless transitions
- keeping older versions around for a time in case the upstream
  ecosystem hasn't upgraded fully yet, and doing it downstream is not
  feasible because the breaking changes are too big

while the latter could be supported even with the non-versioned provides
dropped, the former would not, at least not for rdeps that opt into
relaxing the semver constraints.

the only reason to have an unversioned dep is to not need an immediate
rebuild:
- upload package A with (build-)dep on env-logger >= 0.7 when 0.7 is in the
  archive
-- expecting a compatible 0.8/0.9/..
- env-logger 0.8 gets uploaded at the same time as env-logger-0.7 semver
  variant
-- no need to force an upload of A to partake in the transition
- next regular upload of A can bump the build-dep
- once no rdeps exist, env-logger-0.7 can be RMed

note that the exact version of env-logger that was used to build A is
recorded, so if a grave bug (security or otherwise) is found in either
env-logger 0.8 or 0.7 an update+rebuilds of affected packages can be done.

the only time rdeps should opt into the unversioned scheme is
- they expect the next "breaking" versions to actually be compatible
  (e.g., based on previous track record and/or usage)
- they don't want to take part in rust transition churn

this is the exception rather than the norm (and mostly affects a few
crates that bump often for $reasons, while remaining mostly compatible
for their consumers anyway).

I am not opposed to dropping it if there is a consensus by relevant
teams that the current scheme is bad, I just wanted to explain why it is
currently set up like that.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-rust-maintainers/attachments/20231027/60f49ab6/attachment-0001.sig>