* Don Armstrong <d...@donarmstrong.com>, 2010-08-13, 16:34:
* madcoder-python-transit...@debian.org, 2006-08-01, 12:32: > Hi, your package has been detected as generating a (for most of that >mass bug fill: private) python module/extension that may need an upgrade >to the new Python Policy[1]. [...] > [1] http://lists.debian.org/debian-devel-announce/2006/06/msg00009.htmllilypond builds a private Python extension. Such extensions are normally not binary compatible across different Python versions, so the package must declare tight dependency on the version for which the extension was built. The attached patch fixes this bug.The package which could possibly need a tight dependency isn't lilypond, but lilypond-data;
I am talking about this file: $ dpkg -c lilypond_2.12.3-6_i386.deb | grep -F .so -rw-r--r-- root/root 8008 2010-04-04 05:20 ./usr/lib/lilypond/2.12.3/python/midi.so
secondly, lilypond-data depends on python-support, and it properly calls dh_pysupport in its build-indep rule, and the appropriate calls to it are made in the postinst rule. Now, while I'm not an expert in python packaging, it seems clear that by registering with python-support, on an upgrade to the python interpreter, the rtupdate scripts should result in the private modules being recompiled.
That's true, lilypond-data ships only pure-Python module and python-support takes care of bytecompiling them, and lilypond-data's dependencies are sufficient.
The only problem is lilypond. -- Jakub Wilk
signature.asc
Description: Digital signature
