Re: Debian Python policy & Upgrade Path (draft/proposal)
Quoting Matthias Klose <doko@cs.tu-berlin.de>:
> Carey Evans writes:
> > Matthias Klose <doko@cs.tu-berlin.de> writes:
[...]
> Thanks. Updated in 0.3.2:
>
> http://ftp-master.debian.org/~doko/python/
Nice work updating Neil's policy. I'd be interested to hear Niels comments now
that he is back... Neil, please don't back out now :-)
... some of my comments;
The opening para 1.1 is still based on Neil's original proposal where python-
base was not just a wrapper for the latest pythonX.Y-base. I suggest the
following changes;
----------------------------------------
1.1. Stable and Legacy Versions
-------------------------------
There can be any number of Python packages available. These
must be named `python<X>.<Y>-base' and include the file
`/usr/bin/python<X>.<Y>', where <X> and <Y> represent the major and
minor versions of the Python, respectively.
At any given time, the package `python-base' should establish one of
these packaged versions of Python as the default Debian Python. The
'python-base' package must depend on the default 'python<X>.<Y>-base',
and provide a symlink `/usr/bin/python' to the default
/usr/bin/python<X>.<Y> binary.
1.2. Base Package
-----------------
In order to provide a minimal installation of Python for use by
applications without requiring the whole of Python to be installed,
the `python<X>.<Y>-base' package contains the binary and a basic set of
modules.
---------------------------------------------------------------
Note that I have left it open for the Python developers to decide themselves
which Python should be the Debian default, rather than hard-code into the
policy "... the latest stable upstream version of Python, that Debian is able
to get into the release".
I see you have labeled para 2.3 "Support most/all versions including the
default" as "Not Yet supported". I would suggest that only part 2. of this para
is as yet unsupported, as para 1 describes the working approach used for things
like python-gdbm.
Support of part 2. of this para is dependant on 2 things; agreement on the
symlinking of /usr/lib/python/* from /usr/lib/pythonX.Y/ as a way of supporting
version independant source packages, and scripts to make it easier.
I've posted some scripts, but you guys will probably want to hack at them, if
you want to use them at all. I originaly proposed that each pythonX.Y-base
provide a script for updating itself, and have python-base provide a script
that calls all the pythonX.Y update scripts. After fiddling around, I realised
that the only time the pythonX.Y update scripts would be called would be on
package installation/removal, so it's probably better to just use the
postinst/prerm scripts for each pythonX.Y. The python-base can then provide an
update-python that does them all whenever a new module is installed/removed.
I recall that Neil posted that he had some scripts/packages ready too. I trust
that his work would probably be orders of magnitude better than mine, and so
you are probably better off using his stuff. Mine is probably most interesting
for it's simplicity ('find' is a very powerful beast :-)
Oh yeah, my scripts have the assumption that /usr/local/lib/python* would be
used in the same way as /usr/lib/python*. I see from your policy that this is
not necisarily the case... with /usr/local/lib/site-python being on the path...
won't this cause re-compliation problems when people switch between different
versions of Python?
--
ABO: finger abo@minkirri.apana.org.au for more information.
Reply to: