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 <[EMAIL PROTECTED]> To: Marc Dequènes (Duck) <[EMAIL PROTECTED]> On Wed May 10 2006 07:26, you wrote: > > Coin, > > Bruce Sass <[EMAIL PROTECTED]> 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 -------------------------------------------------------
