Packaging an application with multiple Python versions.
Dear Debian-Pythoners, I want to package HarvestMan for the near future. From the website: http://harvestman.freezope.org HarvestMan is the only public-domain, multithreaded web-crawler program written in the Python language. HarvestMan is released under the GNU General Public License. Now, I have packages ready: python-harvestman, python2.3-harvestman and python2.4-harvestman. I have not filed an ITP yet, because I would like to get two things clarified. 1.The install script provided in the package adds a symbolic link to the executable script present in /usr/lib/python2.x/site-packages/HarvestMan/harvestman.py in /usr/bin/harvestman. Should I do this in my package? If so, how do I handle the case where the Python 2.3 and 2.4 packages both want to be installed simultaneouly? 2.The Python 2.3 and 2.4 packages do the same thing, but use of Python 2.4 allows the program to function with performance improvement. Do I need to take this into account? Advice the user? Also, I do not think it would be correct to add them as Conflicts, as both can peacefully coexist. Comments on this? Thanks. Kumar -- Kumar Appaiah, 462, Jamuna Hostel, Indian Institute of Technology Madras, Chennai - 600 036 signature.asc Description: Digital signature
Re: Packaging an application with multiple Python versions.
Le mardi 07 février 2006 à 18:31 +0530, Kumar Appaiah a écrit : 1.The install script provided in the package adds a symbolic link to the executable script present in /usr/lib/python2.x/site-packages/HarvestMan/harvestman.py in /usr/bin/harvestman. Should I do this in my package? If so, how do I handle the case where the Python 2.3 and 2.4 packages both want to be installed simultaneouly? Maybe you can simply ship this symbolic link in the python-harvestman package. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom
Re: Packaging an application with multiple Python versions.
On Tue, Feb 07, 2006 at 02:00:40PM +0100, Josselin Mouette wrote: Le mardi 07 f?vrier 2006 ? 18:31 +0530, Kumar Appaiah a ?crit : 1.The install script provided in the package adds a symbolic link to the executable script present in /usr/lib/python2.x/site-packages/HarvestMan/harvestman.py in /usr/bin/harvestman. Should I do this in my package? If so, how do I handle the case where the Python 2.3 and 2.4 packages both want to be installed simultaneouly? Maybe you can simply ship this symbolic link in the python-harvestman package. Thanks for the suggestion, but how do I do this? Do I do this from the rules file itself or do I use preinst/postrm? If it is from the rules, how do I add the ln command the right way? Thanks. Kumar -- Kumar Appaiah, 462, Jamuna Hostel, Indian Institute of Technology Madras, Chennai - 600 036 signature.asc Description: Digital signature
Re: Packaging an application with multiple Python versions.
On Tue, Feb 07, 2006 at 02:24:48PM +0100, Josselin Mouette wrote: Le mardi 07 f?vrier 2006 ? 19:03 +0530, Kumar Appaiah a ?crit : Maybe you can simply ship this symbolic link in the python-harvestman package. Thanks for the suggestion, but how do I do this? Do I do this from the rules file itself or do I use preinst/postrm? If it is from the rules, how do I add the ln command the right way? Just add the link in debian/python-harvestman.links, see dh_link(1). Thanks. I guess that settles almost everything. One more thing, do I need to tell the users that quote It is preferred to run HarvestMan with the latest stable release of Python, to get the benefits of all features and for optimal performance. Right now this is Python 2.4.1 /quote like the Readme says? And finally, the documentation is available separately as a (hold your breath) M$ Word document! Now, what do I do with that, given that it is not part of the main package? It is my view that a separate package for it would serve no purpose for a single document. Kumar -- Kumar Appaiah, 462, Jamuna Hostel, Indian Institute of Technology Madras, Chennai - 600 036 signature.asc Description: Digital signature
python-xml up for adoption
Hi, I'm no longer using python-xml[1] for my daily development, and as a consequence, I feel I'm not doing as good a job as I should on the python-xml package. I'm therefore considering passing maintenance to someone else, or co-maintaining the package. The packaging itself is pretty straightforward, but * upstream is not very active * some long lasting bugs[2] are fixed in upstream cvs, but the fix might break other packages depending on the bug, so I'm a bit reluctant to add a patch which could lead to debian shipping a pyxml-0.8.4 package which would behave differently from other distributions * xbel is part of the debian package, but is essentially unmaintained by upstream (not a problem for the DTD, but one for xbel-utils scripts, which I don't use and have been the only one to change in upstream CVS during the past years). Additionnally, xbel has been moved to it's own separate project [3], so maybe it makes sense to move it to its own source package. I'm not sure how this should be done, debian-wise. Is anybody interested in maintaining the package? [1] http://packages.qa.debian.org/p/python-xml.html [2] http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=python-xml [3] http://xbel.sourceforge.net/ -- Alexandre Fayolle signature.asc Description: Digital signature
