On Sat, Sep 29, 2001 at 11:17:19PM -0700, Neil Schemenauer wrote: > Donovan Baarda wrote: > > First off, you need to clarify what you are attempting to achieve. There > > are > > three possibile aims as I see it; > > > > 1) single "official" version of Python in archive/distro. > > 2) multiple alternative versions of Python in archive/distro, only one > > installed at a time. > > 3) multiple alternatives versions of Python installed at a time. > > I am aiming for option 3. There would be one official "python" package. > Most packaged modules depend on that package. If people want to package > older versions of Python they may do so. Those packages are independent > of the "python" package.
This sounds like a hybrid of option 1 and option 3; there is one official version, but other versions can exist, provided they don't trample on the official one. The problem is, the official one _becomes_ the other version when a new official one is released. If you don't take that into account, you end up with an Option1 scenario where every upgrade breaks the old python untill someone creates new "python-X.Y" packages, and half of the new Python is busted because the other support packages haven't been upgraded yet. > > Option 1 means every time Python upgrades, all packages dependant on > > that version of Python are broken and have to be upgraded, with old > > versions removed from the distro. > > 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. > > Your policy seems to be aiming for Option 3... the hardest, but is > > that really what we want? > > Using alternatives for Python is not a good idea, IMHO. The Perl > packagers tried this and it was a nightmare. I agree that alternatives is not necisarily the way to go, I just wanted to make sure it had been considered. The problem is different versions of Python/Perl are not truely interchangeable alternatives. However, the Perl folks are in a slightly different situation because Perl is a required part of Debian, with heaps of other packages depending on it. In some ways, they cannot afford to have more than one alternative of Perl, because it opens up too many possible breakages...and having "one-true-Perl" solves that. IMHO the Perl setup is not that nice, though I'm not sure how it could be made better. IMHO, the best solution given what you have described above is to make each new release of python as a "python-X.Y" package that installs "/usr/bin/pythonX.Y", and have another small "python" package which depends on the latest "python-X.Y" and installs a "/usr/bin/python" link to "/usr/bin/pythonX.Y". This way, when a new version of python comes out, you release a new "python-X.Z" that can co-exist with the old "python-X.Y", and have the new small "python" package update the link(s). Note that support packages compiled against "python-X.Y" will need to do the same trick... have a "python-X.Y-foo" that depends on "python-X.Y", so that old packages of python-foo will work with old versions of python, and can co-exist with new versions for the new python. I'm sorry for bringing this all up now, when it sounds like the policy and packages are basicly done... I was late into this and thought I'd throw in my 2c. -- ---------------------------------------------------------------------- ABO: finger [EMAIL PROTECTED] for more info, including pgp key ----------------------------------------------------------------------
