> There is a main ticket for fixing those non-PEP-440 packages: bug #1991606
this is not the point! Obviously non-PEP-440 compliant packages _in the distro_ must be fixed, independently of broken aptdaemon.
The point is that if somebody includes a third party repo, or installs a not-from-repo python package system-wide, and that package happens to be non-compliant, _it breaks distro upgrade process_. In my pretty firm opinion, it should no be this way.
I understand and agree with the wish to put more order in python packaging. Setuptools refuse to create a non-compliant package? That would be totally fair. But in this case, _uses_ who have no power to fix the problem, and may not even know what's going on, are taken hostage.
@bdrung:
> There is a main ticket for fixing those non-PEP-440 packages: bug #1991606
this is not the point! Obviously non-PEP-440 compliant packages _in the distro_ must be fixed, independently of broken aptdaemon.
The point is that if somebody includes a third party repo, or installs a not-from-repo python package system-wide, and that package happens to be non-compliant, _it breaks distro upgrade process_. In my pretty firm opinion, it should no be this way.
I understand and agree with the wish to put more order in python packaging. Setuptools refuse to create a non-compliant package? That would be totally fair. But in this case, _uses_ who have no power to fix the problem, and may not even know what's going on, are taken hostage.