hi from rust-c-ares!

[dimbleby]

Hey,

I chanced across these forks on crates.io while publishing new versions of c-ares crates; and I guess I'm just curious as to what they're for?! I only looked very briefly, but I didn't yet understand how they were meaningfully different from the originals - perhaps you have plans?

Per the licensing, you are of course welcome to do whatever you like with my code - I am happy that someone is finding it useful.

If you have improvements that would be generally worthwhile, do please consider sending me merge requests...

Thanks!

[zh-jq]

The reasons are:

1. to reduce outdated dependencies such like metadeps, but this is not critical.
2. to get rid of crate winapi, which should be replaced by windows-*, but I'm not familiar with that so I just remove it as we don't have any plan to support windows.
3. to disable the use of vendored compile of c-ares when possible, we decrease the minimum required c-ares to version 1.12.0 and removed the APIs after this version. It's critical for us to control whether we should link with the share library already packaged by distros or just get c-ares static linked.

I prefer to use the original crates if reason 2 and reason 3 could be resolved.
We can discuss further if you think these are useful and possible.

[dimbleby]

I'm not particularly attached to metadeps and I don't see anyone else using it these days. Is there a good reason to get rid of it? If so I'd likely accept a merge request basically reverting dimbleby/rust-c-ares#27

similar for winapi - I'd likely accept a merge request updating this code to use windows-sys instead

support for very old versions of libcares is probably more awkward (and 1.12.0 really is very old). If you want 2016's libcares and 2023's rust code, there's an obvious tension!

• It is intended that if a suitable shared libcares is available then it is used - if that's not working then I'd surely accept fixes
  • of course newer versions of the crates require newer libcares
• I mostly intend that the crates really aren't changing in meaningful ways except for libcares updates, so if you need to use an old libcares you can simply use an old version of the crates too
  • of course that means using older rust dependencies; though if your policies allow you to use 2016's C code I'm not sure that it's very consistent to worry about that
• If there's a sensible way of using feature flags to support older libcares from newer rust code I'm open to that, though I admit that a few minutes thought have not shown me the way

[zh-jq]

I'm not particularly attached to metadeps and I don't see anyone else using it these days. Is there a good reason to get rid of it? If so I'd likely accept a merge request basically reverting dimbleby/rust-c-ares#27

The other option would be switch to system-deps, which is used by GTK bindings.

support for very old versions of libcares is probably more awkward (and 1.12.0 really is very old). If you want 2016's libcares and 2023's rust code, there's an obvious tension!

• It is intended that if a suitable shared libcares is available then it is used - if that's not working then I'd surely accept fixes

  • of course newer versions of the crates require newer libcares

• I mostly intend that the crates really aren't changing in meaningful ways except for libcares updates, so if you need to use an old libcares you can simply use an old version of the crates too

  • of course that means using older rust dependencies; though if your policies allow you to use 2016's C code I'm not sure that it's very consistent to worry about that

• If there's a sensible way of using feature flags to support older libcares from newer rust code I'm open to that, though I admit that a few minutes thought have not shown me the way

The reason to support old versions of c-ares is that many distros we support such as RHEL 8 or Debian 10, still stick to them. Those distros will provide security bug fixes via package managers, so we can avoid to publish new versions when libc-ares need to be fixed.

In order to support multiple versions of libc-ares, we can check the version in build.rs and use explicit cfg flags to enable the new APIs, just like openssl. But as the API is much simpler, it will be easier to use feature flags. In addition to that, a vendored feature flag is always needed to enable musl static compilation.

[dimbleby]

I'm not particularly fussed about system-deps or not, either way is probably fine by me

I might get round to removing metadeps and updating the windows dependency in due course: if you want to get there faster than that, then merge requests are welcome.

If left alone, I'm unlikely to add feature flags and suchlike for support of older libcares. So if you're happy with the status quo, it probably won't happen. But if you are motivated to drive this work then I'd expect to be willing to merge it.

[zh-jq]

If left alone, I'm unlikely to add feature flags and suchlike for support of older libcares. So if you're happy with the status quo, it probably won't happen. But if you are motivated to drive this work then I'd expect to be willing to merge it.

I will try the openssl way once I have time.