Quoting Neil Schemenauer <[EMAIL PROTECTED]>: > 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 [EMAIL PROTECTED] for more information.
