Emit rustc-check-cfg for nightly

[alex]

See https://doc.rust-lang.org/nightly/cargo/reference/build-scripts.html#rustc-check-cfg

[sfackler]

Seems like there's some refactoring to do to make this more maintainable long-term but this looks fine for now.

[sfackler]

🙃

[alex]

yuuuup.

[alex]

TBH this feels motivating to find some way to deprecate and remove support for super old OpenSSL's. Most of this list is for stuff that there's no earthly reason to use.

Not sure how to square that with semver + the need to have a single openssl-sys package though.

[sfackler]

Yeah. openssl-sys breaks are very rough ecosystem-wise, so I might say that an "if a tree falls in the forest" approach is best there.

In the main openssl crate we can (and should, there are a ton of pent up breaks to make) do a bump. We should definitely drop 1.0.1 support. CentOS 7 EOLs in a month or two and I feel like that's probably a decent time to drop 1.0.2 support as well.

[alex]

In terms of openssl-sys, my best idea is:

1. Do a major version bump there, but have openssl support both the old and new major version for an extended period of time.
2. Migrate the rest of the ecosystem to support both
3. Drop support in openssl for the old -sys after the ecosystem has substantially migrated

End users still need a cutover point, but for most of the ecosystem they should be fine.

[sfackler]

There are a ton of crates that directly depend on openssl-sys that would need updating unfortunately: https://crates.io/crates/openssl-sys/reverse_dependencies

[alex]

Yeah, they'd at least be able to migrate incrementally (probably to "supports both"). If they're unmaintained that'd be a problem though.

…

On Sun, May 5, 2024, 11:58 AM Steven Fackler ***@***.***> wrote: There are a ton of crates that directly depend on openssl-sys that would need updating unfortunately: https://crates.io/crates/openssl-sys/reverse_dependencies — Reply to this email directly, view it on GitHub <#2235 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAAGBCOPZFPCHFBUIN6PNLZAZJKFAVCNFSM6AAAAABHHYYNCGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAOJUHA2TSOJVGE> . You are receiving this because you modified the open/close state.Message ID: ***@***.***>

[sfackler]

This may have been fixed, but at least for a while Cargo's version resolution didn't handle constraints like that very well - it would select the newest version even if that would cause two versions to be included in the crate graph.

Probably worth some experimenting to see how things behave now.