Does not build on platforms for which ares_config.h has not been generated about pycares HOT 6 CLOSED

Saúl Ibarra Corretgé, 2016-09-07 02:21-0700:

Those files were generated so long ago I don't even remember :-S I took them from what Node uses, in order to avoid having to use subprocesses and autotools to build pycares. I wouldn't mind adding them to pycares, but I have no way to test those platforms (nor much time at the moment, TBH). If you have working versions for those feel free to send a PR and I'll include it!

I think I will do that: prepare a change that adds generated versions
for these platforms, plus the files to generate them manually for new
platforms if needed, since it is always better to have all the source.

Out of curiosity: how did you get away with packaging it for Debian given I include a bundled and modified c-ares (for good reasons!) ? I thought this was against the policy.

Bundling an existing library goes against the policy indeed, but you are
not: your c-ares is a fork! Still, you have to take care of updating it
if security flaws are discovered in the original…

Librement,

Tanguy

from pycares.

Hi there! Thanks a lot for packaging pycares for Debian! 😍

If you generated config.h with an unmodified config.h.in and configure script from c-ares, or if you modified it but still have it, I could add it to the Debian package and use it to generate config.h (with some kind of Debian-specific patch). Ideally, that should rather be shipped with pycares itself, but I think you had a reason to pre-generate these ares_config.h. Perhaps you could ship it but leave it to the user or distro maintainer to re-generate them it they want to?

Those files were generated so long ago I don't even remember :-S I took them from what Node uses, in order to avoid having to use subprocesses and autotools to build pycares. I wouldn't mind adding them to pycares, but I have no way to test those platforms (nor much time at the moment, TBH). If you have working versions for those feel free to send a PR and I'll include it!

Out of curiosity: how did you get away with packaging it for Debian given I include a bundled and modified c-ares (for good reasons!) ? I thought this was against the policy.

from pycares.

Hello,

I have prepared a new version that can compile on OSes for which the
ares_config.h was not pre-generated, and I will soon upload to Debian.

What is does is that it runs the original c-ares configure script, which
I have added as debian add-on, along with all the other files it needs.
This generates ares_config.h, and also other files like a Makefile,
which I just discard.

Since you refresh files from c-ares from time to time anyway, do you
think you could grab the following ones as well (ares_build.h.in
ares_config.h.in config.guess config.sub configure install-sh
libcares.pc.in Makefile.in), and store them in a directory such as
deps/ares/src/config_source? Even if they are not used normally, this
way they would be there for people that want to regenerate
ares_config.h, for instance to add a new OS or to reflect changes to an
existing one.

Regards,

Tanguy

from pycares.

Hi!

The things the configure script figures out are not something that can change with time IIRC, so I'd rather sip the generated files instead, as we do now. On what platforms did you have to regerate the files? Wouldn't it be easier for Debian (or anyone else, for that matter) to not need any extra patches?

from pycares.

from pycares.

Closing since there is nothing actionable and a long time has passed. If you still want to ship the config files, please send a PR and I'll take a look!

from pycares.