[Pkg-virtualbox-devel] Bug#798491: Non multiarch friendly Depends

[Adam Goldman]

Control: retitle 798491 Packages with Python scripts and non-Python bins aren't multiarch friendly
Control: reassign 798491 dh-python

Hi Gianfranco,

Thanks very much for your fast reply.

> Actually the dependencies are handled by
> 
> Package: virtualbox
> Architecture: amd64 i386
> Pre-Depends: dpkg (>= 1.15.6~)
> Depends: adduser, ${misc:Depends}, ${python:Depends}, ${shlibs:Depends}

Sorry, I had looked at the .deb rather than the source.

> so if something is wrong I guess is because of a bug in python:Depends.

Ah, I guess that explains why there are other broken packages also...

dh-python developers,

Packages that depend on a Python interpreter are getting a Depends: of
python (>= 2.7), python (<< 2.8) . This is OK for packages that only have
scripts in them, because those packages will be Architecture: all. But for
packages that have non-Python binaries and Python scripts in the same
package, the package will end up with a spurious dependency on a specific
arch of the Python interpreter. For example, if installing the amd64
version of such a package, it wouldn't allow installing with the i386
version of the Python interpreter, even if the i386 version of the Python
interpreter is suitable. The result is that on a multiarch system, the 
package management will require that all packages that have Python scripts
and non-Python binaries are the same arch.

For example, this makes it impossible to install virtualbox:amd64 and
cvs2svn:i386 on the same machine.

I believe that instead, Depends: should have
python:any (>= 2.7.5-5~), python:any (<< 2.8) . The reason for bumping the
dependency from 2.7 to 2.7.5-5 is that 2.7.5-5 is the first package
version that had "Multi-Arch: allowed". The package version in jessie is
2.7.9-1, so I think a dep on >=2.7.5-5 is OK when building packages for
jessie or newer.

I expect that any packages that really do require a Python interpreter
with matching arch would also have a dependency on libpython2.7 or similar.
If not, the suggested change would break them.

I'm not sure if #794082 is relevant to this?

-- Adam