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 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?
(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.)
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.
[...]
> 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
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.
Just have them depend on "python-1.5.2" or "python-2.1".
[...]
> 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.
--
Carey Evans http://home.clear.net.nz/pages/c.evans/
"Quiet, you'll miss the humorous conclusion."
