On Tue, 16 May 2017 at 08:00:43 -0400, Barry Warsaw wrote:
> On May 16, 2017, at 11:51 AM, Piotr Ożarowski wrote:
> >packaged as python-enum34 (correct name is python-enum, that's why you
> >didn't find it most probably)
>
> Why is that wrong? Agreed it's perhaps less discoverable in this case, but if
> you were looking for the PyPI enum34 package in Debian, you'd find
> python-enum34 first, and it would make sense.
Debian Python policy is that the package that lets you "import foo"
into /usr/bin/python is named python-foo, because names are APIs and
APIs are names.
If you import this backported module with "import enum" then it should
in principle be python-enum.
That policy does break down if there are two libraries with the same name
and different APIs; it looks as though that might have been the case here.
If that's true, then the python-enum34 name is a hack for encoding "should
be called python-enum according to Policy, but is incompatible with a
previous enum module", in much the same way that ABI-transition suffix names
like libpcrecpp0v5 are a hack for encoding "should be called libpcrecpp0
according to Policy, but is incompatible with a previous libpcrecpp.so.0".
PyPI packages correspond to Debian source packages, not binary packages.
dbus-python (upstream and) on PyPI is the source package dbus-python but
the binary package python-dbus in Debian, because you have to "import dbus"
to use it.
S
