Fwd: Re: multiple pythons and the default
opps, should have sent this one to the list
Sorry for the dup, Marc.
---------- Forwarded Message ----------
Subject: Re: multiple pythons and the default
Date: Wed May 10 2006 14:31
From: Bruce Sass <bmsass@shaw.ca>
To: Marc Dequènes (Duck) <duck@duckcorp.org>
On Wed May 10 2006 07:26, you wrote:
>
> Coin,
>
> Bruce Sass <bmsass@shaw.ca> writes:
>
> > Isn't one of the objectives to reduce the number of Pythons in Debian,
> > so at some point not all versions will be available...
>
> I don't think there is any reason to reduce user's liberty by forcing
> them to use one specific version.
Neither do I, but Debian's managers are concerned about the amount of Python
in the archive.
http://lists.debian.org/debian-python/2006/01/msg00028.html
-----
Furthermore the release team
requested a reduction of the available python versions in etch and and
an easier upgrade procedure when changing the default python version.
-----
<aside - maybe a new subject if anyone wants to persue this>
I've got thoughts about the second part of the quote, but am still
discovering all the issues... currently on dpkg-divert, which looks
like a difficult one and may not be possible to properly handle without
generating local pythonX.Y-foo packages containing *.pyc's (and/or *.pyo's)
and appropriate {pre,post}{inst,rm} scripts. Ya, I'm talking about a
two-stage install, and even then it may not be satisfying because dpkg-divert
doesn't do directories. :-(
Even without considering dpkg-divert, a two-stage install is an interesting
idea to toy with because it would get all the generated files into the dpkg
DB (i.e., in a info/*.list file) and maybe goes part way towards addressing
the "Installed-Size:" problem.
</aside>
> > ...then there are patch releases which may have not made it in yet, or
> > versions which never will because a new interpreter will not be added to
> > stable.
>
> What do you mean by "new interpreter" ? newer version ? Do you mean you
> want both perfect improved stability and bleeding-edge softwares ?
Of course, someone developing with Python will need that.
> > I also think the ability to automatically integrate local interpreters
> > into the system would be a benefit to Python keeners and developers, who may
> > want to use stuff from (say) the Python SVN repository.
>
> I don't think so, if you have any need for another interpreter, this one
> has to be packaged and integrated the Debian way. We cannot handle any
> /usr/local/ installation and manage bugs for broken custom
> installations.
Why can't Debian compile for /usr/local/lib/python and well as /usr/lib/python,
or anywhere else where the only difference between packaged and un-packaged is
simply the PATH? I am not suggesting Debian support local tarball installations,
just that we not ignore obvious infrastructure features which can be extended to
include local bits of Python --- if a user installs python-foo and it is
automatically being bytecompiled for /usr/bin/python2.{4,5}, it seems kinda
silly to make the admins manually install python-foo for their
/usr/local/bin/python2.6 when the only difference is a "local" element in the
PATHs to the interpreter and supporting dirs.
What makes you think that Debian would need to manage bugs in software it
doesn't provide? If anything, this would be a benefit to Debian because we
would get an early warning from keeners when bleeding edge stuff doesn't
automatically work with Debian's infrastructure, packaged modules fail
with an interpreter which hasn't been packaged yet, etc.
- Bruce
-------------------------------------------------------
Reply to: