Re: Question for the transition
On Tue, 4 Sep 2001, Neil Schemenauer wrote: > Jérôme Marant: > > The major question is: do we still need to ship 1.5.2? Unfortunately, > > the old python seems to be necessary since some old packages are not > > compatible with 2.x versions. > > Do you know of any? If you can point them out I may be able to help fix > them. > > Scott Moynes wrote: > > For what it's worth, Zope is not compatible with python 2.x, ... > > AFAIK, Zope 2.4.0 and later is compatible with Python 2.1. I still > don't see the need for multiple versions of Python packages. Any program that exists with Python dependent versions will need multiple versions of Python packages. Maybe Zope today, who knows what tomorrow. Either Debian supports multiple installed versions of Python out-of-the-box, or users start jumping through a bunch of hoops to do it themselves. Keep in mind that Guido himself seems to consider having multiple versions of Python installed to be no big deal, and has even suggested it as a remedy for code breaking changes to the interpreter when the old code can not be easily upgraded (search through the c.l.py PEP238 threads for the first references to Python-3.0 for context). Either Debian supports multiple Pythons, or Debian's users are the ones with the caveat and extra paragraph of instructions (instead of, or in addition to, RH users? ;). Myself, I'm a tinkerer and like the convenience of having everything well integrated into the system... I'd rather tinker with code than with installing Pythons (building docs, fixing #! lines, making menu entries, etc.), someone needing some other Python than the one Debian choose would likely feel the same way (`I wanna run the app, not play with Python'). I'm waiting for the experimental packages to get into unstable so I can make a Debianizing template (i.e., dh_make --custom=template) to simplify packaging up Python alpha releases. I suppose the argument could be made that Debian-stable is not going to see any new packages, so make it consistent and simple ... but that ignores the fact that Debian is just a starting point, who knows what users are going to do with the system. This is not just a coincidence; I seem to recall, from reading about Debian before I even installed it, that Debian is designed to be re-distributed and didn't have (e.g.) a single mail subsystem, users had to choose what they wanted and were expected to have some knowledge about what they were doing. [hmmm, I guess that is also an argument for not requiring perfection out of the implementation] - Bruce
Re: My proposal about sys.path
Jérôme Marant wrote: > Would you please comment on this? Looks reasonable to me. Neil
Experimental Python packages
See here: http://people.debian.org/~nas/woody/ The source packages I have are: python_2.1.1 python1.5_1.5.2 zope2.3.3 These create the following binary packages: python-base python-dev python-elisp python-examples python-gdbm python-mpz python-regrtest python-tk python-xmlbase idle-python python1.5 python1.5-dev zope2.3.3 The zope package depends on python1.5. The dependencies, conficts, replaces, provides fields need to be adjusted yet. There are still a few lintian warnings to be cleaned up yet as well. Also, I'm planning to build new versions of all the packages that don't work with Python 2.1.1 (probably they include extension modules but don't depend on the major and minor version of Python). Before I spend too much time on this, is there a problem with this approach? It seems to be much simpler than using versioned packages for everything Python related. I'm especially interested in Gregor's opinion since he maintains a lot of these packages. Neil
My proposal about sys.path
Hi, One month ago, I posted this: http://lists.debian.org/debian-python/2001/debian-python-200108/msg3.html but I got no reply. Would you please comment on this? Thanks. -- Jérôme Marant <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Re: Proposal for transition--FRD
Mikael Hedin <[EMAIL PROTECTED]> writes: [...] > Why not the exciting name "python"? And confilcts with python-base? > Then all the module that depend on python-base (xxx) to be either > upgrader or removed. Am I right? There's quite a few packages that depend on "python", which is a virtual package, and it looks like it used to be a real package. Try "apt-cache showpkg python". -- Carey Evans http://home.clear.net.nz/pages/c.evans/ You think you know... what's to come... what you are.
Re: Intent for NMU of python-2.1 packages
On 4 Sep 2001, David Maslen wrote: > Gregor Hoffleit <[EMAIL PROTECTED]> writes: > > How does that sound ? > > I think it sounds like an awful lot of work. I still don't really > understand why we keep python1.5, but presumably there are some good > reasons, and I trust the debian team to have thrashed that out by now. > > You mentioned emacs, which made me think about xemacs packaging > system, and wonder how the python packaging system might work for > debian? Probably it doesn't really. > > Ideally I only want to install python2.1 (or whatever the latest > greatest is), but if I did find a need for 1.5 then I would like it to > be able to co-exist. [which is pretty much the answer to your first paragraph, imo] > It would be nice, if I only have 2.1 installed, > for the packaging system to automagically configure python as an > alternative for python2. > > Probably it would be pretty cool if modules could sort out at install > time what version they were to compile for, just like some debian lisp > packages do for different emacsen. Hmmm, (with no regard to robustness)... ~$ locate "*bin/python?.?*" | sed s/bin/lib/ /usr/lib/python1.5 /usr/lib/python2.0 /usr/lib/python2.1 /usr/local/lib/python2.1-local /usr/local/lib/python2.2 ...is probably a good starting point. The installer could try installing everywhere, erasing all traces of failed attempts as it goes along. No need to register anything... but maybe a need to exclude some Python installations from getting stuff installed to them. - Bruce
Re: Proposal for transition--FRD
Carey Evans <[EMAIL PROTECTED]> writes: > Mikael Hedin <[EMAIL PROTECTED]> writes: > > [...] > > > 6) All packages with files in .../python1.5/ without versioned depends > > get a critical bug. > > Unfortunately, this leaves someone's system broken if they just > install some Python packages, and leave the packages that currently > depend on "python-base (>> 1.5.2)" installed. > > The best solution to this is to get rid of python-base, and have all > packages depend on python-base-x.y or similar. Packages only get into Why not the exciting name "python"? And confilcts with python-base? Then all the module that depend on python-base (xxx) to be either upgrader or removed. Am I right? It's really strange that we have no "python" package now, try 'dpkg -p python'. /Micce -- Mikael Hedin, MSc +46 (0)980 79176 Swedish Institute of Space Physics +46 (0)8 344979 (home) Box 812, S-981 28 KIRUNA, Sweden+46 (0)70 5891533 (mobile) [gpg key fingerprint = 387F A8DB DC2A 50E3 FE26 30C4 5793 29D3 C01B 2A22]
Re: Question for the transition
Jérôme Marant wrote: > Neil Schemenauer <[EMAIL PROTECTED]> writes: > > Do you know of any? If you can point them out I may be able to help fix > > them. > > Zope 2.3x was the most obvious example. I don't know if python-ldap can > work with 2.x too. All python packages that provide binary modules > should be check, I think there have been significant changes with C > interfaces. Okay, I've got python-2.1.1 packages. I'm working on python1.5-1.5.2 packages (not python1-1.5.2, the Python binary API changes with major and minor versions but not micro). If Zope is the only thing that needs 1.5.2 then I will try to make zope2.3-x packages. How much should I split up the python1.5.2 source package? I'm included to have just one python1.5.2 binary package. Thoughts? Neil
Re: Proposal for transition--FRD
Mikael Hedin <[EMAIL PROTECTED]> writes: [...] > 6) All packages with files in .../python1.5/ without versioned depends > get a critical bug. Unfortunately, this leaves someone's system broken if they just install some Python packages, and leave the packages that currently depend on "python-base (>> 1.5.2)" installed. The best solution to this is to get rid of python-base, and have all packages depend on python-base-x.y or similar. Packages only get into testing once their dependencies are consistent, and "apt-get upgrade" won't allow broken dependencies either, so this doesn't really cause much hardship. -- Carey Evans http://home.clear.net.nz/pages/c.evans/ You think you know... what's to come... what you are.
Proposal for transition--FRD
Hi, from the thread I started, I propose we try this: 1) Every package that depend on python checks if it works with python 2.1. 2) We upload python-base v. 2.1, and most of the packages will have to make a new upload (depend on python-base (>=2.1 && << 2.2) if anything installed in .../python2.1/). 3) If any package fail 1), we create python1.5-base, and that package will be built accordingly. 4) Everyone be happy with the clean package namespace. 5) This propably mean all packages that depend on python-base (<<1.6) -- which shoud be any with files in .../python1.5/ -- will have to go into testing at the same time. Will this cause a problem? 6) All packages with files in .../python1.5/ without versioned depends get a critical bug. 7) Contemplate the posibility to install modules in /usr/lib/python-modules/, i.e. a version independent place. (I remember the python people have some objection, but forgot which.) 8) Flame me for writing long task lists. /Micce -- Mikael Hedin, MSc +46 (0)980 79176 Swedish Institute of Space Physics +46 (0)8 344979 (home) Box 812, S-981 28 KIRUNA, Sweden+46 (0)70 5891533 (mobile) [gpg key fingerprint = 387F A8DB DC2A 50E3 FE26 30C4 5793 29D3 C01B 2A22]
Re: Question for the transition
Neil Schemenauer <[EMAIL PROTECTED]> writes: > Jérôme Marant: > > The major question is: do we still need to ship 1.5.2? Unfortunately, > > the old python seems to be necessary since some old packages are not > > compatible with 2.x versions. > > Do you know of any? If you can point them out I may be able to help fix > them. Zope 2.3x was the most obvious example. I don't know if python-ldap can work with 2.x too. All python packages that provide binary modules should be check, I think there have been significant changes with C interfaces. -- Jérôme Marant <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Re: Question for the transition
Neil Schemenauer <[EMAIL PROTECTED]> writes: > Jim Penny wrote: > > This is not all that simple. python2.1 conflicts with zope2.3.x > > and python1.5 conflicts with zope2.4.x. > > In that case I think it's better to create python1.5 and zope2.3 > legacy packages for people who can't upgrade. I prefer this approach. A legacy package which a few people will have installed for a period of transition. Everyone else uses the latest version of python-base. If something breaks (like zope) then you reinstall the old package and report a bug. The zope maintainer can then add a dependancy like requires python <= 1.5
