Bug#814069: python-six-whl and python-pip-whl: error when trying to install together
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]
Bug#814069: python-six-whl and python-pip-whl: error when trying to install together
On Feb 08, 2016, at 10:51 AM, Colin Watson wrote: >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? -whl packages really only exist for pip and virtualenv. As per Debian Python policy, they shouldn't be used for anything else in the archive. It used to be that the only way we could provide those .whl files was to build them when we built the dependent packages, thus we had to add python-six-whl and others. But now we have dirtbike, which is a tool to turn .deb provided packages back into wheels, so pip and virtualenv build whatever they need using dirtbike in their own d/rules files, and have Built-Using headers to at least document this; or at least *did* - it looks like some things got lost or mis-merged from an earlier branch :( So where we ultimately want to end up is that python-six-whl and the others go away. Instead, we'll have only python-pip-whl and another -whl package in virtualenv to provide a few additional requirements. I haven't uploaded or file bugs for the appropriate changes in the dependent packages yet. I thought I had everything working locally and ready to go, but I've run into a few snafus which I'm still working out. Anyway, that's the plan. As you mention, this really is a transitional period and I thought it would go more smoothly. /usr/share/python-wheels will not have two paths owned by two different packages once this is done. Debian Python Policy has been updated in bzr but not yet pushed out (there are other unrelated changes pending). You're right Colin, that this bug really belongs in pip and I think it should be duped to #813399; which I closed over the weekend, but maybe not correctly. You might be right about the << dependencies, in which case, let's keep this bug (#814069) as a separate bug, but move it to python-pip. Hopefully that makes sense. Apologies for all the brokenness I've introduced. I had some work priorities that unfortunately interrupted this transition, but I'll be working only on this transition now until it's all fixed. pgpfpd8bbaFFh.pgp Description: OpenPGP digital signature
Bug#814069: python-six-whl and python-pip-whl: error when trying to install together
Package: python-pip-whl,python-six-whl Version: python-pip-whl/8.0.2-3 Version: python-six-whl/1.10.0-2 Severity: serious User: trei...@debian.org Usertags: edos-file-overwrite Date: 2016-02-08 Architecture: amd64 Distribution: sid Hi, automatic installation tests of packages that share a file and at the same time do not conflict by their package dependency relationships has detected the following problem: 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) This is a serious bug as it makes installation fail, and violates sections 7.6.1 and 10.1 of the policy. An optimal solution would consist in only one of the packages installing that file, and renaming or removing the file in the other package. Depending on the circumstances you might also consider Replace relations or file diversions. If the conflicting situation cannot be resolved then, as a last resort, the two packages have to declare a mutual Conflict. Please take into account that Replaces, Conflicts and diversions should only be used when packages provide different implementations for the same functionality. 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. -Ralf. PS: for more information about the detection of file overwrite errors of this kind see http://qa.debian.org/dose/file-overwrites.html.
