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
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: 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.
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: 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.
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]
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
Re: My proposal about sys.path
Jérôme Marant wrote: Would you please comment on this? Looks reasonable to me. Neil
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 period... 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
