On Wed, Sep 18, 2013 at 06:24:13PM +0200, Jakub Wilk wrote: > Following the “if it didn't happen on a mailing list, it didn't > happen”, I repeat here what I said on IRC:
> 12:26 < kwilk> So I rebuilt src:python-aalib, and I ended up these Depends: > "python3:any (>= 3.3.2-2~), libaa1". > 12:27 < kwilk> This is wrong; the package only works if the interpreter > architecture is the same as libaa1 architecture. > 12:27 < kwilk> Please revert this ":any" mess. > 12:30 < kwilk> In general, just because a script or a module is pure-Python > doesn't mean it doesn't care about interpreter's architecture. > 12:30 < kwilk> And there's no way to determine automatically whether it cares > or not. Nonsense. It's not in the purview of the script/module to care about the architecture of the interpreter. There are cases for which a package that ships a python script / pure python module *does* care about the architecture of the interpreter, but this is *not* because of the script / module itself - it's only because of architecture-specific python extensions included in the same package, which is expressed via a separate arch-specific dependency on libpython; or because of restrictions on the architecture-availability of the other python modules the package depends on, which should be handled by the package manager and *not* hard-coded in the dependencies of the package in question. The operative principle is that the admin should be able to select a /usr/bin/python of any architecture capable of being run on the hardware, and packages that only contain python scripts/modules should Just Work, with apt doing the heavy lifting to ensure the right set of compiled extensions are available to match. This is important for users to be able to successfully cross-grade from one architecture to another, but it's even more important for cross-building, because packages that build-depend on python-using packages need to be able to install the foreign-arch version of those packages *without* changing the architecture of the python interpreter. There are admittedly bugs in apt that caused the first cut of the dh-python support to not work as expected (bug #723586 filed on apt), but that doesn't warrant reverting the :any handling. Piotr has already updated dh-python to address the serious symptoms of bug #723586 to avoid propagating any further breakage while we identify a better solution. As a strawman, if there's a consensus that it's important to preserve the capability to install jessie module packages on top of wheezy's python, we could generate dependencies such as: python:any (>= 2.7.5-5) | python (>= 2.6.6-3) which I think would DTRT in all cases except where you try to cross-install on top of the wheezy python, which is a negligible use case. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ slanga...@ubuntu.com vor...@debian.org
signature.asc
Description: Digital signature
