Some now unneeded code in python3-setuptools is dropped, there are further
changes like this which can follow.
This change was verified with OE-Core by comparing task-depends.dot generated
by "bitbake world -g" before and after the change, the files were identical.
diff --git a/meta/recipes-devtools/python/python3-setuptools_51.0.0.bb b/meta/recipes-devtools/python/python3-setuptools_51.0.0.bb
index 6ee935f8f79..db336bfa13b 100644
--- a/meta/recipes-devtools/python/python3-setuptools_51.0.0.bb
+++ b/meta/recipes-devtools/python/python3-setuptools_51.0.0.bb
@@ -58,8 +58,3 @@ RDEPENDS_${PYTHON_PN}-pkg-resources = "\
${PYTHON_PN}-plistlib \
${PYTHON_PN}-pprint \
"
-# Due to the way OE-Core implemented native recipes, the native class cannot
-# have a dependency on something that is not a recipe name. Work around that by
-# manually setting RPROVIDES.
-RDEPENDS_${PN}_append = " ${PYTHON_PN}-pkg-resources"
-RPROVIDES_append_class-native = " ${PYTHON_PN}-pkg-resources-native"
The runtime dependency on ${PYTHON_PN}-pkg-resources isn't needed anymore? I don't see how it would get still included as you said that bitbake -g files were the same.
I'm asking because meta-python2 has the same issue in:
and my fix I was planing to send was to replace it with:
RDEPENDS_${PN}_append_class-target = " ${PYTHON_PN}-pkg-resources"
and drop the RPROVIDES, because it unfortunately causes bitbake to get stuck after reporting parsing error as: