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.
signature.asc
Description: PGP signature