Re: Debian Python policy.
Quoting Neil Schemenauer <nas@python.ca>:
> Donovan Baarda wrote:
> > On Sat, Sep 29, 2001 at 11:17:19PM -0700, Neil Schemenauer wrote:
> > > Donovan Baarda wrote:
> > > If you change the major or minor version of Python installed then
> > > packages that depend on it must be upgraded. There is no way around
> > > that.
> >
> > Yes, but the old packages still work for the old version of Python.
> One of
> > the main reasons to continue running old versions of Python is because
> other
> > packages haven't been updated yet.
>
> Try to think exactly how this would work. On the surface is seems like
> a good idea but I think it leads to a lot of complexity and more work in
> the end for the maintainers. Say I have a Python program "foo" that
In some ways yes... in some ways no. You get all the python-X.Y packages for
old versions for free, because they are created as you go. Mantainers of
version specific modules create python-X.Y-foo packages and python-foo wrapper
packages (see below). This is a little worse thatn just creating a python-foo
package every time python upgrades, but not worse than creating python-foo and
an old python-X.Y-foo.
>From archive updating point of view, my scheme has a large python-X.Y-foo added
and a small python-foo updated when python upgrades. Your scheme has a large
python-foo updated and a large python-X.Y-foo added, where python-X.Y-foo is
mostly the same as the old python-foo.
That is, if you actualy intend to produce python-X.Y packages... I suspect you
wouldn't bother with your scheme.
> requires "python-bar". Let's say the installed version of Python is
> 2.0. So "python-bar" installs its modules into /usr/lib/python2.0.
> "foo" depends on "python-bar" and uses /usr/bin/python. What happens
> when /usr/bin/python becomes Python 2.1? Oops, it doesn't have the
> "python-bar" modules. Okay, how about we make "foo" use
> /usr/bin/python2.0. Now we upgrade to Python 2.1 and every works fine.
> Now we upgrade "python-bar" so that it installs in /usr/lib/python2.1.
> Oops, "foo" is broken again. I think it only solution is to have the
> version in the package name for all Python packages. Now instead of
yes... every python package that depends on a particular version of python
would need to have the python version in the name. This is a pain, but it's the
only way I can see to have a true "Option 3" scenario. Even your scheme of
supporting old python-X.Y packages would requires old python-X.Y-foo packages
to go with them.
Something that does complicate it all is even python modules that are version-
independant become tied to a particular version when they are installed
into /usr/lib/python-X.Y (as in your python-bar above). There are a few ways
around this, none pretty;
1) have python-foo which depends on python (>=X.Y) install into /usr/lib/python-
X.Y, and have all python-M.N packages add all /usr/lib/pythonA.B to their path
where A.B <= M.N, in highest version first order. This means python-foo will be
un-available when running pythonM.N where M.N < X.Y.
2) have python-foo which depends on python (>=X.Y) install
into /usr/lib/python, and have all python-M.N packages add /usr/lib/python to
their path after /usr/lib/pythonM.N. Note that running pythonM.N where M.N <
X.Y and attempting to use python-foo will break.
3) have python-foo which depends on python (>=X.Y) install
into /usr/lib/python, and install links in /usr/lib/pythonA.B/
to /usr/lib/python/* for all A.B >= X.Y. Note that these links will need to be
updated every time a new python-X.Y or python-foo is installed. Perhaps a
utility "update-links" function in the python (X.Y) package should be provided
to do this.
Note that 1) and 2) will break if a python upgrade changes the python byte-
code. Only 3) is bytecode-change-resistant.
> updating all the modules when a new version of Python is installed you
> have to update all the modules and the the programs that use Python as
> well.
There is a way around this; every versioned package has an un-
versioned "wrapper" package; python (X.Y) depends on python-X.Y, python-foo
depends on python-X.Y-foo, and program bar depends on python (>=X.Y) and python-
foo. This way any program that is mostly independant of the python version will
always use the latest python. Programs that depend on a particular version of
python can depend on python-X.Y and perhaps python-X.Y-foo.
> You've added a large amount of complexity to handle some easily repaired
> breakage that happens to the unstable version of Debian about once per
> year. I don't think that's a good tradeoff.
Perhaps, but IMHO it's the only way to realisticly and efficiently
support "Option 3". Of course, this is academic if you just aim for "Option
1" :-)
--
ABO: finger abo@minkirri.apana.org.au for more information.
Reply to: