Re: Experimental Python packages
Neil Schemenauer [EMAIL PROTECTED] writes: python_2.1.1 python1.5_1.5.2 zope2.3.3 Why not python-1.5_1.5.2, zope-2.3.3 and similar binary packages? I think this namenumber scheme is ugly and it looks strange. name-version is more clear IMO. These create the following binary packages: python-base python-dev python-elisp Why not python instead of python? I want to be able to apt-get install python and dpkg -p python. Then python could confilct with python-base, and in that way force all old module packages that depend on python-base to get updated to their new version that depend on python (= 1.5), python (1.6). /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: Experimental Python packages
Gregor Hoffleit [EMAIL PROTECTED] writes: Have you looked at my experimental Python packages, at http://people.debian.org/~flight/python/snapshot/ ? I've had a look at these packages myself. Can you tell us what stage they're at, i.e. what still needs to be done, what problems you know about and what you want to hear about? Some things I've noticed to start with: - Lots of references to Python 1.5 or 2.0. - python2.1-base tries to install an alternative for /usr/bin/python in its postinst, so it has to conflict with old versions of python-base that contain this. - The shlibs file refers to python2-base (= 2.1-1) but the package is python2.1-base. - /usr/bin/pydoc isn't versioned, so python2.2-base will have to conflict with this version of python2.1-base. It should probably be /usr/bin/pydoc2.1 with a pydoc alternative, and start with #!/usr/bin/python2.x as appropriate, for future versions. I'd also like to know: - What dependencies should packaged modules declare: a) when the maintainer only plans on supported whatever the latest version of Python is? b) if there'll be one package per Python version? - What should packages that use Python depend on? Presumably python if the maintainer feels optimistic, otherwise python2.1-base. -- Carey Evans http://home.clear.net.nz/pages/c.evans/ You think you know... what's to come... what you are.
Re: Experimental Python packages
Gregor Hoffleit wrote: Have you looked at my experimental Python packages, at http://people.debian.org/~flight/python/snapshot/ ? I haven't yet tried your packages, but it sounds like you started from scratch ? No, I based them on your python and python2 packages. I've made quite a few bug fixes to them so you might want to do a diff between them an your packages. You'll have to ignore all the s/python2/python/ changes. Neil
Re: Experimental Python packages
* Neil Schemenauer [EMAIL PROTECTED] [010906 16:27]: Gregor Hoffleit wrote: Have you looked at my experimental Python packages, at http://people.debian.org/~flight/python/snapshot/ ? I haven't yet tried your packages, but it sounds like you started from scratch ? No, I based them on your python and python2 packages. I've made quite a few bug fixes to them so you might want to do a diff between them an your packages. You'll have to ignore all the s/python2/python/ changes. Ok, thanks for the effort! In the experimental packages, the biggest difference is the modified build setup in ./debian/., which should make it much easier to package new upstream versions like 2.2. Gregor
Re: Question for the transition
On Thu, 6 Sep 2001, Neil Schemenauer wrote: Bruce Sass wrote: 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. I'm not saying Debian shouldn't support multiple installed versions of Python. I'm saying that the current stable version of Python should be in the package python or python-base. Most packages would depend on python. Old or experimental versions of Python should be called python-major.minor. Ok... but isn't that what causes the problems -- packages depending on python when they really depend on python-major.minor. - Bruce
Re: Question for the transition
So file bug on the packages in question. They could also depend on python(=1.5), python(1.6). See my other postings on this. /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: Experimental Python packages
Bruce Sass wrote: On Thu, 6 Sep 2001, Neil Schemenauer wrote: Again the package is python-base, not python2.2-base. pydoc depends on python-base_2.1.1 and uses #!/usr/bin/python. I don't see a problem with that. Except you don't know which Python /usr/bin/python is. Please think a little. pydoc is in the same package as python-base. Neil
Re: Updated idea for transition
On 6 Sep 2001, Mikael Hedin wrote: What about doing as gcc? Produce python-1.5, python-2.1 and so on forever. And then have a package python that just drags in the official version, and links /usr/bin/python. If we nuke python-base, all old modules get upgradrd I think. (Similar for python-foo etc.) Sure ( ;-) ), and anything depending on python is expected to work with any version of Python... that leads to the problem of how to install something that depends on any Python, to every Python on the system without duplicating all the .py-s. It would be easy if python had two paths to deal with; one for version independent .py-s only (in a read-only directory), another for .py|c|o (read-write). Code that didn't care which Python executes it would be installed in the r-o dir, the .pyc|o-s resulting from a compile would automatically get stored in the r-w dir. Is this kind of enhancement suitable as a Debian-only tweak, or would it need to be part of Python itself? How long would it take to implement... for Python?, for Debian? - Bruce
Re: Experimental Python packages
On Thu, Sep 06, 2001 at 12:38:42PM -0700, Neil Schemenauer wrote: | Bruce Sass wrote: | On Thu, 6 Sep 2001, Neil Schemenauer wrote: | Again the package is python-base, not python2.2-base. pydoc depends on | python-base_2.1.1 and uses #!/usr/bin/python. I don't see a problem | with that. | | Except you don't know which Python /usr/bin/python is. | | Please think a little. pydoc is in the same package as python-base. I think the admin should be able to choose which python implementation is referred to by /usr/bin/python independent of which python (or python-base if you prefer) packages are installed (the alternatives mechanism may be a good idea for this). There can be any number of reasons why an admin would want a certain implementation to be the default. These reasons could include o understanding a certain version knowing it works (before upgrading and finding unexpected breakage) o Jython or Stackless -D
Re: Question for the transition
On 6 Sep 2001, Mikael Hedin wrote: So file bug on the packages in question. They could also depend on python(=1.5), python(1.6). See my other postings on this. I see it as the difference between putting a gate on the corral, and running around trying to round up the livestock whenever they get out. Either can work, but I'll trade reading... Package: python-2.1.1 Provides: python-2.1, python with filing bug reports and dealing with third-party packages that don't know Debian, anyday. - Bruce
Re: Experimental Python packages
On Thu, 6 Sep 2001, Neil Schemenauer wrote: Bruce Sass wrote: On Thu, 6 Sep 2001, Neil Schemenauer wrote: Again the package is python-base, not python2.2-base. pydoc depends on python-base_2.1.1 and uses #!/usr/bin/python. I don't see a problem with that. Except you don't know which Python /usr/bin/python is. Please think a little. pydoc is in the same package as python-base. I guess I need some help... The python-base package gives me python-python2.1, from Python-2.1.1. What happens when I point python to python3.0, will pydoc still work. Why should Debian decide that bin/python _must_be_ a specific version of Python when it is so simple to specify which python a executable needs. Gratuitous is the only word I can think of that accurately describes behaviour like that. Pydoc is part of Python, so there should be no problem explicitly specifying which Python that is (it is not limiting in any way). The experimental py-2.1 packages have: 1) #/usr/bin/env python2 it should be: 2) #/usr/bin/env python2.1 because Python uses either python or pythonmajor.minor you (Neil) want: 3) #/usr/bin/python I like 2) because it lets me have a /usr/local/bin/python2.1 overshadow the packaged 2.1 if I want, simply by fiddling with symlinks in /usr/local/bin. If every executable did that I could point python to whatever I wanted and things just work. 1) may have well been /usr/bin/python2, because I've never seen reference to a bin/pythonmajor outside of Debian; the only python2 around will be Debian's. 3) may well only work if python happens to point to Python-2.1.x ...where has my thinking failed? - Bruce
Re: Updated idea for transition
On 6 Sep 2001, Mikael Hedin wrote: What about doing as gcc? Produce python-1.5, python-2.1 and so on forever. And then have a package python that just drags in the official version, and links /usr/bin/python. If we nuke python-base, all old modules get upgradrd I think. (Similar for python-foo etc.) Sure ( ;-) ), and anything depending on python is expected to work with any version of Python... that leads to the problem of how to install something that depends on any Python, to every Python on the system without duplicating all the .py-s. It would be easy if python had two paths to deal with; one for version independent .py-s only (in a read-only directory), another for .py|c|o (read-write). Code that didn't care which Python executes it would be installed in the r-o dir, the .pyc|o-s resulting from a compile would automatically get stored in the r-w dir. Is this kind of enhancement suitable as a Debian-only tweak, or would it need to be part of Python itself? How long would it take to implement... for Python?, for Debian? I think it's unrealistic to assume that any sizeable package will be completely independent from the Python version, unless the author has this as one of the explicit project goals. But if you want this, I would certainly be willing to take a patch. It would be a relatively small amount of code, but it would have to be repeated in a few places (import.c, py_compile.py, a few more places). --Guido van Rossum (home page: http://www.python.org/~guido/)
