what to do about python-kjbuckets
Hi, I maintain python-kjbuckets, so I'm supposed to update it to conform to the new policy. But there is a problem: The current (from 1997) upstream version[1] doesn't work with Python = 2.0. Now, Berthold Hoellmann, Oleg Broytmann and others have ported[2] kjbuckets to work with newer Pythons, but it's not as official as one could hope. For instance, the version number is still the same as the old upstream version (2.2). I'm not sure what to do. Here's a couple of solutions: 1) Don't include python-kjbuckets in Debian. (Easy, boring and maybe unsatisfactory since at least routeplanner depends on it and gadfly recommends it.) 2) Only make a python1.5-kjbuckets package. (Nah.) 3) Call the new package something else. (Doesn't really solve the problem, since updates to the port aren't followed by a version number bump.) 4) Use an epoch version, i.e. 1:2.2. (Ugh.) 5) Use date in version, i.e. 2.2.port.20011104 or similar. (Best solution I can come up with.) Opinions? Regards, Joel [1] Found at: http://www.pythonpros.com/arw/kjbuckets/ [2] Available here: http://phd.pp.ru/Software/Python/#kjbuckets -- Joel Rosdahl [EMAIL PROTECTED] (PGP and GPG keys available)
Re: Packaging python-egenix-mx*
Matthias Klose [EMAIL PROTECTED] writes: Federico Di Gregorio writes: On Sun, 2001-10-28 at 22:34, Joel Rosdahl wrote: 3. As the policy mandates, I have made the packages depend on python (= 2.1), python ( 2.2) Lintian doesn't really like that. :-) For example: E: python-egenix-mxdatetime: package-has-a-duplicate-relation python N: N: The package seems to declare a relation on another package more than N: once. This is not only sloppy but can break some tools N: Okay, this wasn't a question, just a note. Which tools are this? Basically the error should prevent something like python (=1.x), python ( 1.y). I don't know. :-/ 4. Any other comments? Oh, and if anyone wants to look at or test the packages, get them here: deb http://joel.rosdahl.net/debian/ ./ deb-src http://joel.rosdahl.net/debian/ ./ looks ok. Would it make sense to add a 'Replaces:' line for those packages without the '-egenix' part? I.E: Package: python-egenix-mxdatetime Replaces: python-mxdatetime No, I don't think so, since they aren't compatible (e.g. to use mxDateTime 1.3.0 you import DateTime, but to use mxDateTime 2.0.2 you import mx.DateTime). Could you copy these packages to ftp-master.debian.org in ~doko/www/python-uploads? Will do today or tomorrow. Regards, Joel -- Joel Rosdahl [EMAIL PROTECTED] (PGP and GPG keys available)
Re: (2nd try) Final draft of Python Policy (hopefully ;-)
Matthias Klose [EMAIL PROTECTED] writes: It let's a package depend on: python (= 2.1), python ( 2.2), python-foo and can expect a working default Python version, which has support for python-foo. You mean python, python-foo I presume? My proposal would be to build 1.5 and 2.0 packages from one source and 2.1 and 2.2 packages from another source package, so the first source package and binary packages can easily be removed. Why is this easier or better than uploading a new version of the source package that just builds 2.1 and 2.2 packages? Joel -- Joel Rosdahl [EMAIL PROTECTED] (PGP and GPG keys available)
Packaging python-egenix-mx*
Hi, I have now finished Debianizing eGenix mx BASE (based on patch done by Federico Di Gregorio, see bug#56): http://www.lemburg.com/files/python/eGenix-mx-Extensions.html The upstream maintainer of the mx packages (mxdatetime, mxstack, mxtools, ...) now distributes everything in one source package, so I have used egenix-mx-base as source package name. It currently builds the following binary packages compiled for Python 2.1: python-egenix-mxbeebase python-egenix-mxdatetime (new version of python-mxdatetime) python-egenix-mxproxy python-egenix-mxqueue python-egenix-mxstack (new version of python-mxstack) python-egenix-mxtexttools (new version of python-mxtexttools) python-egenix-mxtools (new version of python-mxtools) and also python-egenix-mx-base-dev which includes headers for the C API to the libraries. Questions: 1. Does anyone need Python 1.5 versions of these packages? Packages I have found that are associated with some of the mx packages are: python-mysqldb (Suggests: python-mxdatetime) python-popy (Depends: python-mxdatetime) python-psycopg (Depends: python-mxdatetime) python-reportlab (Suggests: python-mxtexttools) but I currently assume that no one of those will need Python 1.5. Is my assumption incorrect? 2. Should I build Python 2.2 versions of these packages (i.e. will woody include Python 2.2(beta))? 3. As the policy mandates, I have made the packages depend on python (= 2.1), python ( 2.2) Lintian doesn't really like that. :-) For example: E: python-egenix-mxdatetime: package-has-a-duplicate-relation python N: N: The package seems to declare a relation on another package more than N: once. This is not only sloppy but can break some tools N: Okay, this wasn't a question, just a note. 4. Any other comments? Oh, and if anyone wants to look at or test the packages, get them here: deb http://joel.rosdahl.net/debian/ ./ deb-src http://joel.rosdahl.net/debian/ ./ Regards, Joel -- Joel Rosdahl [EMAIL PROTECTED] (PGP and GPG keys available)
