Hello!

I'm trying to update rust-minreq, so we can eventually get rid of rustls-0.21
(due to[1][2][3], as far as I can tell this debian-rust team package is
currently the only reason rustls-0.21 is still needed).

[1]: https://rustsec.debian.net/advisories/RUSTSEC-2026-0098.html
[2]: https://rustsec.debian.net/advisories/RUSTSEC-2026-0099.html
[3]: https://rustsec.debian.net/advisories/RUSTSEC-2026-0104.html

When building, I get the following error:

```
E: Unable to satisfy dependencies. Reached two conflicting assignments:
    1. librust-minreq-dev:amd64=3.0.0-1 is selected for install because:
       1. satisfy:command-line:amd64=1 is selected for install
       2. satisfy:command-line:amd64 Depends librust-minreq-dev
       3. librust-minreq-dev:amd64 is available in versions 3.0.0-1, 2.13.4-4+b1
          [selected librust-minreq-dev:amd64]
       For context, additional choices that could not be installed:
       * In librust-minreq-dev:amd64 is available in versions 3.0.0-1, 2.13.4-4+b1:
         - librust-minreq-dev:amd64=2.13.4-4+b1 is not selected for install
    2. librust-minreq-dev:amd64=3.0.0-1 Depends librust-rustls-0.23+default-dev
(>= 0.23.35)
       but none of the choices are installable:
       [no choices]
librust-minreq-dev:https FAIL badpkg
```

I could verify `librust-rustls-0.23+default-dev` is indeed not available:

```
$ apt install -s librust-rustls-0.23+default-dev
NOTE: This is only a simulation!
       apt needs root privileges for real execution.
       Keep also in mind that locking is deactivated,
       so don't depend on the relevance to the real current situation!

Error: Unable to locate package librust-rustls-0.23+default-dev
Error: Couldn't find any package by glob 'librust-rustls-0.23+default-dev'
```

With the +default suffix removed it's installable however:

```
$ apt install -s librust-rustls-0.23-dev
NOTE: This is only a simulation!
       apt needs root privileges for real execution.
       Keep also in mind that locking is deactivated,
       so don't depend on the relevance to the real current situation!

Note, selecting 'librust-rustls-dev' instead of 'librust-rustls-0.23-dev'
Installing:
   librust-rustls-dev

Installing dependencies:
   librust-aho-corasick-dev         librust-equivalent-dev
librust-serde-derive-dev
   librust-alloc-no-stdlib-dev      librust-erased-serde-dev
librust-serde-dev
[...]
```

Please add a +default provides so dependency resolution works for crates that
depend on rustls with default features, and no other feature enabled.

Thank you! :)

Quoting kpcyrd (2026-10-11 13:25:09)

It is true that the Debian packaging of rustls does not provide the
"default" feature.

I will be happy to offer that feature when in fact it is available.

I will not, however, claim it being available before it truly is, in
the contained crate.

If your package succeeds with a fake declaration, then please consider
adjusting your package, as that is proof that your package does not, in
fact, require "default" from rustls.

 - Jonas

I'm not sure I understand, depending on rustls with default features is
perfectly valid:

cargo new test123 && cd test123 && echo 'rustls = "0.23"' >> Cargo.toml && cargo
build
off the `default` feature dependency:

```
Depends:
  ${misc:Depends},
  librust-base64-0.22+default-dev,
  librust-log-0.4+default-dev,
  librust-native-tls-0.2+default-dev,
  librust-openssl-0.10+default-dev (>= 0.10.29),
  librust-openssl-0.10+vendored-dev (>= 0.10.29),
  librust-openssl-probe-0.2+default-dev,
  librust-punycode-0.4+default-dev (>= 0.4.1),
  librust-rustls-0.23+default-dev (>= 0.23.35),
  librust-rustls-0.23+ring-dev (>= 0.23.35),
  librust-rustls-platform-verifier-0.6+default-dev (>= 0.6.2),
  librust-serde-1+default-dev (>= 1.0.101),
  librust-serde-json-1+default-dev,
  librust-urlencoding-2+default-dev (>= 2.1.0)
```

The default feature set is always available in Rust and always enabled unless
`default-features = false` is added:

https://doc.rust-lang.org/cargo/reference/features.html#the-default-feature

You are allowed to make opinionated choices like "the default feature set should
use the ring feature instead of the aws-lc-sys feature", that would be better
than making every package patch in `default-features = false` and come up with
their own sensible list of rustls default features.

Quoting kpcyrd (2026-10-11 17:57:42)

I agree that I am allowed to deviate from upstream, but disagree that
it is sensible - I would consider that a fork, which I am not willing
to maintain:

If I patch rustls to use ring by default, then any downstream consumer
of rustls that expects aws-lc-sys to be in use will fail.

 - Jonas

It's a fork either way, but removing a supposedly always-available default
feature breaks 100% of downstream consumers, while ring vs aws-lc-sys is some
internal implementation detail. :)

Quoting kpcyrd (2026-10-11 18:19:36)

Agreed, it is a fork either way.

 - Jonas