Re: zope, zope-popyda, psycopg and python1.5-{,egenix-}mxdatetime
Joel Rosdahl <[EMAIL PROTECTED]> writes:
> 1. build python1.5 versions of all egenix mx packages (easier and more
>consequent, but also bloatier)
python1.5 versions of all egenix mx packages are now in incoming.
Joel
--
Joel Rosdahl <[EMAIL PROTECTED]> (PGP and GPG keys available)
Re: zope, zope-popyda, psycopg and python1.5-{,egenix-}mxdatetime
Federico Di Gregorio <[EMAIL PROTECTED]> writes: > On Tue, 2001-11-20 at 21:24, Jérôme Marant wrote: > > Joel Rosdahl <[EMAIL PROTECTED]> writes: > > > > > Sounds like you guys could use a python1.5 version of > > > mxdatetime, then... > > the ones without egenix in the name? too old. I was vague on purpose since I didn't know if the 1.3.0 or 2.0.2 version was needed. > > > I'm willing to maintain such a package, but the best solution is > > > maybe that one of you creates a separate python1.5 mxdatetime > > > package as you like and also maintains it? > > i can maintain the egenix stuff if you like (after all i wrote the > original patches to build egenix 2.0.2) but splitting the package > is, imo, a bad thing. it should be maintaned by a signle developer > (doesn't matter who.) Yes, since it's the new version we're talking about, I too think it's better not to split the package. But there was some talk on this list about that it would be better to use different source packages in some cases. For example, in http://lists.debian.org/debian-python/2001/debian-python-200110/msg00140.html Mathias writes: | > Have all these packages to be built with the same source? | | No. Although it avoids source code duplication, it makes it more | difficult to remove an older version. 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. In http://lists.debian.org/debian-python/2001/debian-python-200110/msg00142.html I asked why it would be better to do it this way instead of just uploading (when 1.5 is obsolete) a new version of the source package that simply doesn't include the obsolete binary packages. But now when I read his answer in http://lists.debian.org/debian-python/2001/debian-python-200110/msg00143.html I think he maybe misunderstood me. Care to elaborate, Mathias? Anyway, do you think I should 1. build python1.5 versions of all egenix mx packages (easier and more consequent, but also bloatier), or 2. build just a python1.5-egenix-mxdatetime? Regards, Joel -- Joel Rosdahl <[EMAIL PROTECTED]> (PGP and GPG keys available)
Re: zope, zope-popyda, psycopg and python1.5-{,egenix-}mxdatetime
Federico Di Gregorio <[EMAIL PROTECTED]> writes: > On Mon, 2001-11-19 at 21:29, Jim Penny wrote: > > Thinking about fog's reply: > > > > was there an earlier python-egenix-mxdatetime compiled for 1.5? > > > > I have > > Package: python-egenix-mxdatetime > > Version: 2.0.2-5 > > Depends: python (>= 2.1), python (<< 2.2), python2.1-egenix-mxdatetime > > > > which is certainly not going to be compatible (or even findable) by > > a zope1.5 extension. > > > > I wonder if we have gotten lucky because people who needed python-psyco > > (now python1.5-psyco) are pinned by some other dependency so that > > their python-egenix-mxdatetime has not been replaced? > > no. it was my fault. my devel machine has a strange combination of > packages satisfying the dpendencies and an old mxdatetime 2.0.2 compiled > by myself in /usr/lib/python1.5/site-packages making the > python1.5-psycopg package working. the package now in debian is b0rken. > sic. > > > Postscript: fog, does that mean that you intend to continue to maintain > > python1.5-psycopg for a while? > > at least until python1.5 exits from debian. Sounds like you guys could use a python1.5 version of mxdatetime, then... I'm willing to maintain such a package, but the best solution is maybe that one of you creates a separate python1.5 mxdatetime package as you like and also maintains it? Regards, Joel -- Joel Rosdahl <[EMAIL PROTECTED]> (PGP and GPG keys available)
zope, zope-popyda, psycopg and python1.5-{,egenix-}mxdatetime
Good evening, Does anyone have opinions on this? Is there a need for a python1.5-mxdatetime (based on the old mxdatetime) or a python1.5-egenix-mxdatetime (based on the new egenix mxdatetime)? --- Begin Message --- On Mon, Nov 19, 2001 at 07:33:59PM +0100, Joel Rosdahl wrote: > [EMAIL PROTECTED] writes: > > > Package: python-mxdatetime > > Version: N/A > > Severity: important > > (Did you mean to send this to [EMAIL PROTECTED]) Actually, I did send it. But it bounced with a weird message about headers. Anyway, I prefer to talk to people before filing a bug. > > > Please prepare a python1.5-mxdatetime that has the correct > > dependencies for python1.5. This would be very useful to someone > > who needs extra time to migrate from zope2.3 to zope2.4, for > > example. > > > > The current package conflicts with python1.5. This should be a > > simple matter of changing one dependency, and perhaps a conflicts > > with python-mxdatetime and replaces python-mxdatetime. > > python-mx* has been replaced by python-egenix-mx*, and I have asked > the FTP maintainers to remove python-mx* from testing and unstable. > So the conflict between the new python packages and python-mxdatetime > is expected. :-) > > I don't know much about Zope, but the indications I've received are > that no Debian packages need python-egenix-mx* compiled for Python > 1.5. At least zope-popyda and psycopg depend on it (for python1.5). I suspect that pgsql and possibly pygresql (deprecated but still there), do as well. (as long as the zope 2.3 exists in testing, and possibly longer.) You might check with [EMAIL PROTECTED] and [EMAIL PROTECTED] about their intentions W.r.t python1.5. (You may certainly forward this to them.) I would prefer to maintain the option for python-popy at least for now. The zope maintainer believes that he can transition people from zope2.3.x to zope2.4.x painlessly. I have been through at least three upgrades, and can testify that it usually is quite pain filled. Objects are often pickled in ZODB in a way that is not completely compatible with the upgraded version. At very least, it requires massive testing. I have no strong opinion on the -mxdatetime versus egenix-mxdatetime for 1.5. To be conservative, 1.5 ought to be about making no big changes at this time, so I guess I would mildly prefer -mxdatetime, on the principle of the "devil you know". > > (But you maybe mean that Debian should have a python1.5-mxdatetime so > that people who have installed Zope manually don't need to also > install mxdatetime manually?) people who have installed manually zope and these packages are not really important; the packages in question all are heavily automaked and have proven moderately difficult for limited skill people to install. But, as zope source-installs in a quite FHS unfriendly way, it would be quite difficult for a .deb to figure out where to install them, anyway, so they must have managed somehow. No, what I am worried about is people who do an upgrade and suddenly have massive breakage. I would like to preserve at the the option of backing down to zope2.3. And I think that there remain a handful of other important programs that still require 1.5. > > Regards, > Joel Thanks for your time and attention. Jim > > > -- > Joel Rosdahl <[EMAIL PROTECTED]> (PGP and GPG keys available) > --- End Message --- -- Joel Rosdahl <[EMAIL PROTECTED]> (PGP and GPG keys available)
Re: what to do about python-kjbuckets
Donovan Baarda <[EMAIL PROTECTED]> writes: > I would hope that you also make a python1.5-kjbuckets so that older > python1.5 programs that used it can still use it. You them also make > a python2.2-kjbuckets (2.2.0-port.20011104) package if you want > something newer. > > If you want to support the default python, you need a > python2.1-kjbuckets and an empty python-kjbuckets package that has > "Depends: python (>=2.1), python (<<2.2), python2.1-kjbuckets". Or > you could wait untill 2.2 becomes the default python... python-kjbuckets, python2.1-kjbuckets and python2.2-kjbuckets are now in incoming. (Same for python*-egenix-*; I've built python2.2-* versions too.) As Matthias Klose said, do we really need python1.5 versions of kjbuckets (or python-egenix-*, for that matter)? Just say the word and I'll package them. :-) Regards, Joel -- Joel Rosdahl <[EMAIL PROTECTED]> (PGP and GPG keys available)
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: Packaging python-egenix-mx*
Donovan Baarda <[EMAIL PROTECTED]> writes: > My only suggestion is, if you are at all in doubt about supporting > multiple versions of python, don't use the 2.1.1 "support only the > default" packaging option, instead use the 2.1.3-1. "multiple > versioned packages" option. > > Note that even if you choose the "multiple versioned packages" > option, you are not required to support all versions, only the > default. This allows you to easily add multiple version support > later on if you wish. It actualy gives you multiple version support > for free as you produce new packages, as each new version doesn't > break your old packages. > > It might seem like more work initially, but I'm sure in the long run > it will work out easier. That's a suggestion I expected. :-) Actually, I initially made a version that builds 1.5 and 2.1 versions of the packages along with empty dummy packages that depend on their respective 2.1 versions. When I later thought about not building 1.5 versions, I decided to test the 2.1.1 packaging option to get rid of the dummy packages (and to see whether anyone had comments about it). So it's not much work for me to switch to the 2.1.3-1 scheme again, and if both Python 2.2 (in some form) will be included in woody I definitely will use it (the scheme, that is). Regards, Joel -- Joel Rosdahl <[EMAIL PROTECTED]> (PGP and GPG keys available)
Re: Packaging python-egenix-mx*
Federico Di Gregorio <[EMAIL PROTECTED]> writes: > On Sun, 2001-10-28 at 22:34, Joel Rosdahl wrote: > > python-egenix-mx-base-dev > > note that the location of the header files was wrong in my patch > (/usr/include/pythonx.y/mx is much better, imho.) Agreed and changed. > > 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) > > i plan to drop support for 1.5 from psycopg (at least in debian > builds) when we'll have a zope for python 2.1 in the archive. Okay. Will this happen in woody? Regards, 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)
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)
Re: Debian Python policy & Upgrade Path (draft/proposal)
Ricardo Javier Cardenes <[EMAIL PROTECTED]> writes:
> I have fixed that, but not uploaded the package while the policy is
> on debate. I suppose this is the case of other maintainers too...
Yep.
Joel
--
Joel Rosdahl <[EMAIL PROTECTED]> (PGP and GPG keys available)
