Re: python-enchant is not importable in python 2.6 on armhf. Any idea which package is at fault?
On Mon, Dec 26, 2011, peter green wrote:
> According to the launchpad "meta-bug" the python2.7 fix was already
> uploaded to
> unstable. This would fit with my test succeeding with python2.7 and
> failing with
> Python2.6 (ubuntu) in the launchpad meta-bug is marked as "won't fix"
> because python2.6 is "to be removed" are there any plans to fix
> python2.6 in
> debian or do they plan to remove it like ubuntu do?
(python2.6 will eventually be removed from Debian but depending on how
long it will stay, its maintainer might opt to use the patch in this
> > It would be best if we would patch python programs and modules to stop
> > using find_library.
> Should a bug be opened against python-enchant? and if so what should the package use instead of find_library?
You would file a bug against the python-enchant package or the
pyenchant source package. The code using find_library is in
enchant/_enchant.py, _e_path_possibilities() yields some pathnames
where the library should be loaded from:
"""Generator yielding possible locations of the enchant library."""
if sys.platform == 'darwin':
# enchant lib installed by macports
as you can see, this doesn't encode the SONAME anywhere, so that if the
ABI / SONAME change and the old and new ones are present, a random one
will be chosen. Ideally, the code would gain awareness of the
ABIs / SONAMEs that pyenchant actually works with and do something
for soname in ('libenchant.so.1', 'libenchant.so.0'):
e = cdll.LoadLibrary(soname)
this could be used by default for all unixish systems, but I guess
upstream would still want PYENCHANT_LIBRARY_PATH to be preferred in
(The above snippet would be used somewhere near line 119 "# Not found
yet, search various standard system locations." in enchant/_enchant.py
and would try libenchant.so.1 and fall back to libenchant.so.0).