Make most dependencies depend on the selection state of the respective
plugins requiring them. This cuts down compile time considerably when
plugins like MySQL support are disabled.
Signed-off-by: Jo-Philipp Wich <jo@mein.io>
Write *.ip file with current registered IP, whenever "get_registered_IP" is called (used by next luci-app-ddns version)
Changed detection of cURL proxy support #3876
Reread data from ubus if "get_local_ip" from "ip_network" #5004#3338
Fix godaddy_com_v1 #5285
Implement "param_opt" for "cloudflare_com_v4" #5097
Inside logfile "*password*" printed in stead of real password #5281 and others
Add ipv4 service "dnsever.com" #5178
Add ipv4 service "myip.co.ua" #5199
Signed-off-by: Christian Schoenebeck <christian.schoenebeck@gmail.com>
python3 variant
Renaming the package is needed to allow for a Python 3 variant
(python3-zope-interface). Packages that depend on this (only twisted)
also have their dependencies adjusted.
Signed-off-by: Jeffery To <jeffery.to@gmail.com>
This guarantees for the package feeds that
the mk files will always be available for all packages.
Will need to see about external-feed Python packages
a bit later.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
The only difference just a parameter for Python3
[ -b to compile bytecodes in legacy mode ].
No need to keep 2 almost identical files now
that they're exported.
I'm a bit scared of that param, since it may get
removed at some point.
But let's see until then.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Since `lang/python` is it's own folder of Python packages
(for both Python 2 & 3), and these build rules are needed
in a lot of packages [especially Python packages],
putting them here makes sense architecturally,
to be shared.
This also helps get rid of the `include_mk` construct
which relies on OpenWrt core to provide, and seems
like a broken design idea that has persisted for a while.
Reason is: it requires that Python 2/3 be built to provide
these mk files for other Python packages,
which seems like a bad idea.
Long-term, there could be an issue where some other feeds
would require these mk files [e.g. telephony] for
some Python packages.
We'll see how we handle this a bit later.
For now we limit this to this feed.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
The .mk snippets are not really usable at the moment, as they cannot be
considered for metadata collection (package DUMP) when included through
include_mk. Python packages do not use include_mk anymore for this reason,
so the install commands can be removed as well.
Signed-off-by: Matthias Schiffer <mschiffer@universe-factory.net>