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 [cjwat...@debian.org]