Bug#256283: [pylucene-dev] Re: PyLucence Debian Package
Regarding the swig incompatibility, I think you are right. It probably
is a matter
of poking the right people and waiting.
However, it is technically possible to compile on Debian stable then upload the
binary package to unstable (a.k.a. sid). This can - somewhat - bypass the swig
issue and get a working PyLucene package in Debian for one architecture,
presumably i386. Once the swig issue gets straightened out, the
autobuilders will be
able to handle the other architectures.
I know this sounds yucky, but it's not that uncommon. Usually the way it goes
is a package builds on unstable, gets added to Debian, some build dependency
gets updated, then the build breaks, and the package gets a FTBFS
(fails to build
from source) bug, then someone fixes it. Debian has been dealing with this type
of problem for a long time with reasonable success.
The gcj situation is more serious. No way in hell can we package the gcj
runtime inside the PyLucene package. As far as I can tell this is a
although I'm curious what the gcj package maintainers have to say
about the matter.
As for things to do, here's the best list I can think of:
- find out what the real story is for getting into backports.org
- help make sure the right people have the right information. Is Andi in good
contact with the Swig authors already? Do they need more detailed
- I noticed the package is only valid for python-2.4. Most Debian python
packages support multiple versions of python. Maybe this is something
to work on while other paths are blocked?
- See if our counterparts in RedHat, Gentoo, Suse, etc. have made progress
on any of these issues. (Unlikely, I suspect otherwise Andi would know about
Finally, Matthew I'd like to know your estimated attention span as we consider
the possibility of putting a semi-broken package into Debian. My comfort zone
for [get it fairly good first] vs [put it in then improve it] shifts a
little depending on
whether you have short term or long term interest.