python-sqlalchemy-ext 0.7.2-1~bpo60+1 not installable (file conflict with python-sqlalchemy)
Hello,
python-sqlalchemy-ext 0.7.2-1~bpo60+1 is not installable due to a file-conflict
with python-sqlalchemy:
The following NEW packages will be installed:
python-sqlalchemy-ext
0 upgraded, 1 newly installed, 0 to remove and 48 not upgraded.
Need to get 0 B/21.9 kB of archives.
After this operation, 156 kB of additional disk space will be used.
(Reading database ... 150406 files and directories currently installed.)
Unpacking python-sqlalchemy-ext (from .../python-sqlalchemy-ext_0.7.2-1~bpo60+1_amd64.deb) ...
dpkg: error processing /var/cache/apt/archives/python-sqlalchemy-ext_0.7.2-1~bpo60+1_amd64.deb (--unpack):
trying to overwrite '/usr/lib/python2.5/site-packages/sqlalchemy/cresultproxy.so', which is also in package python-sqlalchemy 0.7.2-1~bpo60+1
configured to not write apport reports
Errors were encountered while processing:
/var/cache/apt/archives/python-sqlalchemy-ext_0.7.2-1~bpo60+1_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)
Looking at the conflicting files they shouldn't be in the arch:all package at all:
$ file /usr/lib/python2.5/site-packages/sqlalchemy/*.so
/usr/lib/python2.5/site-packages/sqlalchemy/cprocessors.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, not stripped
/usr/lib/python2.5/site-packages/sqlalchemy/cresultproxy.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, not stripped
I remember seeing this too when doing a local backport of python-sqlalchemy
in the past. IIRC it was because for python2.5 the .so files are moved from
the wrong location. They got already installed into debian/python-sqlalchemy
before they get moved from the build directory into the
python-sqlalchemy-ext package resulting in getting included in both
packages. For python2.6 (and later) the .so files get moved from the
python-sqlalchemy package directory (and not the build directory) to the
python-sqlalchemy-ext package. So the fix is to use the same mv call for
python2.5 as for python2.6.
Regards,
Michael
Reply to: