Re: Debian Python policy.
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 abo@minkirri.apana.org.au for more info, including pgp key
----------------------------------------------------------------------
Reply to: