Re: Status report on python2 transition (possible solution)
On Sat, Jul 14, 2001 at 11:27:55AM +1200, Carey Evans wrote:
| D-Man <dsh8290@rit.edu> 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
Reply to: