Re: Status report on python2 transition (possible solution)
D-Man [EMAIL PROTECTED] writes: Yes. Maybe each extension should just depend on a single version of python and need to be rebuilt for each new python release. It makes things considerably simpler, from my point of view. Then, of course, we need unique package names for each package. Something like python-imaging-python1.5, python-imaging-python2.0 and python-imaging-2.1? Aagh. (Picking on python-imaging because it contains binary modules, so it's version specific anyway.) | Are there any other reasons to provide all the modules for Python | 1.5.2 (now more than two years old) in Debian 3.0? Who knows what people might be using that isn't packaged for Debian. True. I feel that we can't keep everyone happy forever, and Python 1.5 has to go away someday; OTOH, I'm running quite up to date unstable, so maybe I don't have the same perspective as many users. ;) -- Carey Evans http://home.clear.net.nz/pages/c.evans/ Quiet, you'll miss the humorous conclusion.
Re: Status report on python2 transition (possible solution)
On Sat, Jul 14, 2001 at 04:05:56PM +1200, Carey Evans wrote: | D-Man [EMAIL PROTECTED] writes: | | Yes. Maybe each extension should just depend on a single version of | python and need to be rebuilt for each new python release. | | It makes things considerably simpler, from my point of view. | | Then, of course, we need unique package names for each package. Yeah | Something like python-imaging-python1.5, python-imaging-python2.0 | and python-imaging-2.1? Aagh. Since we have python1.5 and python2.1, how about python1.5-imaging and python2.1-imaging. Then if the maintainer wants to include a version on the package it could be (I don't know PIL's version) python2.1-imaging2.3. I don't think that is too ugly. | (Picking on python-imaging because it contains binary modules, so it's | version specific anyway.) | | | Are there any other reasons to provide all the modules for Python | | 1.5.2 (now more than two years old) in Debian 3.0? | | Who knows what people might be using that isn't packaged for Debian. | | True. I feel that we can't keep everyone happy forever, and Python | 1.5 has to go away someday; OTOH, I'm running quite up to date | unstable, so maybe I don't have the same perspective as many users. ;) I agree with both of those, though I think that at least one old version should be kept. I don't think 1.5.2 needs to disappear quite yet because it is the most common version (in a lot of diff. environments). It could probably go in the next (after woody) release because by then 2.x will have filled it place as the most commonly used. -D
Re: Status report on python2 transition (possible solution)
On Fri, Jul 13, 2001 at 03:25:20PM -0400, D-Man wrote: ... o The #! line should look something like #!/usr/bin/deb_py_ver 1.5.2 - I can't get things like this to work. It seems one parameter atmost is allowed there. That's why I proposed this symlink trick the other day. Then the first line would look like: #!/usr/bin/python1.5.2- #!/usr/bin/python1.5.2-2.0 and all would work. Very debian specific and all, but it would allow precise description of the versions the script works with. -- groetjes, carel
Re: Status report on python2 transition (possible solution)
On Fri, 13 Jul 2001, D-Man wrote: On Fri, Jul 13, 2001 at 11:30:28PM +0200, Carel Fellinger wrote: | On Fri, Jul 13, 2001 at 03:25:20PM -0400, D-Man wrote: | ... | o The #! line should look something like | #!/usr/bin/deb_py_ver 1.5.2 - | | I can't get things like this to work. It seems one parameter at | most is allowed there. Huh? The idea was that there would be a script/program named deb_py_ver. It would take 2 command-line arguments and determine which python binary should be used. It would then exec that python on the script (which, IIRC, is on stdin of deb_py_ver). This would allow having a single program, rather than an exponentially growing number of symlinks. Otherwise the symlink idea is the simplest implementation, except for handling which package to put each link in. It has something to do with the #! thing. e.g., SYNOPSIS env [OPTION]... [-] [NAME=VALUE]... [COMMAND [ARG]...] yet if you do #!/usr/bin/env command arg you get a message about command arg not being found. - Bruce
Re: Status report on python2 transition (possible solution)
On Fri, Jul 13, 2001 at 06:27:20PM -0400, David M. Cooke wrote: | At some point, D-Man [EMAIL PROTECTED] wrote: | On Fri, Jul 13, 2001 at 11:30:28PM +0200, Carel Fellinger wrote: | | On Fri, Jul 13, 2001 at 03:25:20PM -0400, D-Man wrote: | | ... | | o The #! line should look something like | | #!/usr/bin/deb_py_ver 1.5.2 - | | | | I can't get things like this to work. It seems one parameter at | | most is allowed there. | | Huh? The idea was that there would be a script/program named | deb_py_ver. It would take 2 command-line arguments and determine | which python binary should be used. It would then exec that python on | the script (which, IIRC, is on stdin of deb_py_ver). This would allow | having a single program, rather than an exponentially growing number | of symlinks. Otherwise the symlink idea is the simplest | implementation, except for handling which package to put each link in. | | That's not the problem -- the problem is that the command specified in | the #! is passed the rest of the line as _one_ argument (at least on | Linux). That's why you can't do, for instance, | | #!/usr/bin/env python -O | | as the first line. I thought that would work, which is why I was confused :-). | I suppose you could split the argument on spaces -- although I'm not sure if | other Unices (the Hurd, anyone?) pass the rest of the line or just the first | argument. | | Another alternative would be | | #!/usr/bin/deb_py_ver 1.5.2- | | and | | #!/usr/bin/deb_py_ver 1.5.2-2.1.1 | | That's one argument. Ok, sure, replace the space separator between the versions with a different ASCII separator. -D
Re: Status report on python2 transition (possible solution)
On Sat, Jul 14, 2001 at 11:27:55AM +1200, Carey Evans wrote: | D-Man [EMAIL PROTECTED] writes: | | o all core (the interpreter) python packages will be versioned | ex | python-1.5.2 | python-2.0 | python-2.1.1 | | Each of these will contain /usr/bin/pythonX.Y.Z and provide | 'python'. | | It might be more convenient to have a separate package called | 'python'. This could depend on the latest Python to make apt-get | dist-upgrade work, and conflict with any old packages that are a | problem (like the current python-base). It might be more convenient, unless a user, for some strange reason, wants to only have an older version of python. | It would also provide the /usr/bin/python symlink, if it doesn't get | managed by alternatives. Since the python command will be for users, | should the sysadmin really get to choose an older version for them? Why shouldn't the sysadmin get to choose? Suppose a new python is released, but the admin is afraid that his scripts (suppose they use 'python' too) might not work with it. He might want the default python to stay the same (the now old version) while installing the new one to start migrating to. | (See the gcc, gcc-2.95 and gcc-3.0 packages, where /usr/bin/gcc is a | symlink to /usr/bin/gcc-2.95; except on hppa which uses gcc 3.0.) Are you saying that gcc 2.95 and 3.0 can peacefully co-exist on a system? That would be good news to me :-). | BTW, I would suggest python-2.1 instead; 2.1.1 is only a bug-fix | release, even if the license is one of the bugs, and 2.1.2 will be the | same if it's ever released. Ok, if that is the naming convention that is preferred. | o all other packages will have a versioned depends on the lowest | version it runs with, also a max version if it exists | | I wouldn't like to try to be clairvoyant if I was packaging a Python Sure, but also consider older packages. For example, we are now moving to 2.0 (or 2.1) for the default python. We still want to provide 1.5.2 versions of all the other packages, so they should (now) specify that they don't work with = 2.0 because we know that now. | script; how about just depending on the latest version in the archive | that it works with. One of the problems at the moment is that almost | all packages using Python optimistically depend on = 1.5.2. Either it is optimistic, or there was no known conflict with a newer version (because it didn't exist ;-)) when it was built. | Just have them depend on python-1.5.2 or python-2.1. Ok. So we have a version of each extension package to match with each version of python currently supported. I have no problem with that. | o /usr/bin/deb_py_ver will be a script/program that takes 2 | arguments, a min version and a max version of python that can be | used to run this script. | | Can I suggest that with only a few weeks until Python freezes, | anything like this is left until the following Debian release? That | will give us several months to iron out any bugs in the script, and in | the packages using it, before time runs out. Well, I have no fancy title (like Debian Maintainer) so I really have no authority on the matter. The idea just came to me and it seemed pretty good so I thought I'd share it :-). You can do what you like with the idea. -D
Re: Status report on python2 transition (possible solution)
D-Man [EMAIL PROTECTED] writes: It might be more convenient, unless a user, for some strange reason, wants to only have an older version of python. In which case they won't have anything else installed that depends on python, and they'll just install python-2.1, for example, and never see python-2.2. Given this, /usr/bin/python better be managed by alternatives. [...] Are you saying that gcc 2.95 and 3.0 can peacefully co-exist on a system? That would be good news to me :-). Yep. There's still the familiar problem of differing C++ ABIs, so everything in woody should still be compiled with gcc 2.95. [...] Sure, but also consider older packages. For example, we are now moving to 2.0 (or 2.1) for the default python. We still want to provide 1.5.2 versions of all the other packages, so they should (now) specify that they don't work with = 2.0 because we know that now. However, that can lead to packages breaking when a new version of Python is installed, without pulling in the newer extension modules and packages that use the new scope rules properly, and have variables named yield and div renamed to something else, etc. dpkg and apt provide very good dependency checking, so we should try to use it. Anyway, *do* we actually need all the extension modules for Python 1.5.2? For Debian itself, there's Zope and Mailman, but they don't depend on any other Python packages. reportbug uses python-newt, but it should be changed once python-2.1 is available, so that Python 1.5.2 isn't installed by default on new Debian 3.0 installations. Are there any other reasons to provide all the modules for Python 1.5.2 (now more than two years old) in Debian 3.0? Either it is optimistic, or there was no known conflict with a newer version (because it didn't exist ;-)) when it was built. This may be true, especially when Python 2, which would break lots of stuff, was in the distant future. Python 3K may be far away now, but Python 2.x is breaking stuff with every release. Well, I have no fancy title (like Debian Maintainer) so I really have no authority on the matter. The idea just came to me and it seemed pretty good so I thought I'd share it :-). You can do what you like with the idea. I probably shouldn't be using my @debian.org address for this discussion anyway; I've done one package upload in the last six months, which hardly makes me an active Debian maintainer or any kind of authority. I'm not really talking just to you, but generally; by all means keep coming up with ideas to improve the Debian Python packages, but please don't keep Python 2.1 out of Debian 3.0! -- Carey Evans http://home.clear.net.nz/pages/c.evans/ I'm not the only one who disagrees with everything. - Fur Patrol, _Man In A Box_
Re: Status report on python2 transition (possible solution)
D-Man [EMAIL PROTECTED] writes: Say, ..., is there a way for a python script to find out where the python binary executing it is? If so, then the real script could be run via os.system by the Debian script that uses #! deb_py_ver. sys.executable, which comes from argv[0] in Py_Main(), looking in $PATH if necessary. os.system isn't the best in terms of signal handling and return values; you'd probably want os.execv. -- Carey Evans http://home.clear.net.nz/pages/c.evans/ Quiet, you'll miss the humorous conclusion.
