[Python-modules-team] Bug#814069: python-six-whl and python-pip-whl: error when trying to install together

[Colin Watson]

On Mon, Feb 08, 2016 at 08:11:22AM +0100, Ralf Treinen wrote:
> Selecting previously unselected package python-pip-whl.
> (Reading database ... 10940 files and directories currently installed.)
> Preparing to unpack .../python-pip-whl_8.0.2-3_all.deb ...
> Unpacking python-pip-whl (8.0.2-3) ...
> Selecting previously unselected package python-six-whl.
> Preparing to unpack .../python-six-whl_1.10.0-2_all.deb ...
> Unpacking python-six-whl (1.10.0-2) ...
> dpkg: error processing archive /var/cache/apt/archives/python-six-whl_1.10.0-2_all.deb (--unpack):
>  trying to overwrite '/usr/share/python-wheels/six-1.10.0-py2.py3-none-any.whl', which is also in package python-pip-whl 8.0.2-3
> Errors were encountered while processing:
>  /var/cache/apt/archives/python-six-whl_1.10.0-2_all.deb
> E: Sub-process /usr/bin/dpkg returned an error code (1)

Looks like https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=813399, but
more of the same.  Barry, shouldn't you be doing something like
"python-six-whl (<< 1.10.0+)", rather than these sketchy <= dependencies
on specific packaging revisions that are going to break when we do
something innocuous in six?

The whole way this devendoring is handled seems very very sketchy
anyway.  I take it that you're trying to ensure that pip has
exactly-versioned wheels available even when (e.g.) six moves on to a
newer upstream version?  In that case, I suggest finding a way to ship
the necessary wheels in a directory private to pip instead of in
/usr/share/python-wheels/.  We really shouldn't be deliberately shipping
the same file in two different packages for more than just temporary
transitional purposes.

> Here is a list of files that are known to be shared by both packages
> (according to the Contents file for sid/amd64, which may be
> slightly out of sync):
> 
>   /usr/share/python-wheels/six-1.10.0-py2.py3-none-any.whl
> 
> This bug has been filed against both packages. If you, the maintainers of
> the two packages in question, have agreed on which of the packages will
> resolve the problem please reassign the bug to that package. You may then
> also register in the BTS that the other package is affected by the bug.

I would be inclined to argue that this path clearly belongs to the
python-six-whl package.  Barry, do you agree with me reassigning this
bug to python-pip-whl?

-- 
Colin Watson                                       [cjwatson at debian.org]