Jeff Breidenbach [EMAIL PROTECTED] said: > 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.
Okay, so this is what I'd want to do if the GCC folks respond and say GCJ 3.4.x (x >= 3) will be in Unstable. Since GCC 3.4.4 is in Unstable I'm mildly optimistic GCJ 3.4.x will be as well. > 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 showstopper, although I'm > curious what the gcj package maintainers have to say about > the matter. Yes, I agree, without GCJ runtime support there can be no PyLucene package. :( > 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. If things resolve themselves such that a package could actually make it into Debian then I'd certainly take a long-term responsibility for it. I'd like to see it happen. As you suggested, if Andi agrees I think providing a link to a .deb for Debian Stable (Sarge) from the PyLucene website is the best short-term solution. This would take into account the shifting RC status of Lucene 1.9, the GCJ issues in Debian Unstable, the SWIG issues, and it makes something available to folks. -matthew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
