On Thu, 28 Nov 2019 at 11:15:31 -0500, Sandro Tosi wrote: > if you install `pubsub` as top-level module, your package must be > named pythonN-pubsub, if not it violates the policy and it's RC buggy.
That's what I had thought, but I've also seen people asserting that the Debian package name ought to reflect the egg name in cases where it differs from the top-level Python module name. Some examples of where the difference between egg name and module name matters: - this one: - module: pubsub (-> python3-pubsub) - egg: pypubsub-*.egg-info (-> python3-pypubsub) - is actually python3-pypubsub (named for the egg) - src:dbus-python: - module: dbus (-> python3-dbus) - egg: dbus_python-1.2.14.egg-info (-> python3-dbus-python) - is actually python3-dbus (named for the module) - src:pygobject: - module: gi (-> python3-gi) and pygtkcompat - egg: PyGObject-3.34.0.egg-info (-> python3-pygobject) - is actually python3-gi (named for the module) (Maybe python3-gi should also have Provides: python3-pygtkcompat?) Is there consensus that the top-level module name is what matters, and not following the recommendation is a bug? https://www.debian.org/doc/packaging-manuals/python-policy/module_packages.html says "The binary package for module foo should preferably be named python3-foo, if the module name allows" and "import foo should import the module", which suggests that it is indeed the name of the top-level importable module, and not the name of the egg, that matters (which would imply that -dbus and -gi are correct, and -pypubsub is not). Is there consensus that not following this recommendation is a *RC* bug? The bits I quoted above say "should" rather than "must". Thanks, smcv
