Has Red Hat helped or hurt?
Tim Roberts
administration activities. Ordinarily, I'd say this was a Good Thing for
the betterment and furtherance of Python.
However, it makes it deucedly difficult to upgrade away from 1.52. If one
upgrades /usr/bin/python to be 2.x, all of Red Hat's custom configuration
scripts are no longer found in site-packages.
How have other people handled this? Do you just copy all of
1.52/site-packages to 2.x/site-packages? Do you install Python 2.x into a
separate directory and grumble every time you have to change the #! line in
your scripts? I tried updating all of the #! lines in the Red Hat scripts,
but this, of course, blows as soon as you do an rpm upgrade of a
Python-based package.
--
- Tim Roberts, ti...@probo.com
Providenza & Boekelheide, Inc.
Paul Rubin
> Red Hat 7.x uses Python 1.52 for many of its configuration and
> administration activities. Ordinarily, I'd say this was a Good Thing for
> the betterment and furtherance of Python.
>
> However, it makes it deucedly difficult to upgrade away from 1.52. If one
> upgrades /usr/bin/python to be 2.x, all of Red Hat's custom configuration
> scripts are no longer found in site-packages.
I don't think it's a fair question. Red Hat is just another Python user
and the implied criticism of them for using 1.5.2 is unreasonable.
1.5.2 was the latest and greatest Python version when the Red Hat 7.x
series began, and per perfectly reasobale policy, Red Hat is staying
with it for as long as 7.x lasts. Red Hat 8.x will probably use Python 2.2
or whatever is current when 8.0 comes out.
It's also bogus to speak of Python 1.5.2 as some ancient dinosaur that
should be dead and gone. It's just 2 years old or so. It's quite
normal for people to never upgrade software except when they buy new
computers, and to buy new computers about once every 2 hardware
generations. By Moore's law, a hardware generation is about 18
months. So there's nothing stone-age about running 3 year old
software. Python 1.5.2 should be considered outdated but not
obsolete. It's an error to needlessly break compatibility with it.
Martin v. Loewis
> How have other people handled this? Do you just copy all of
> 1.52/site-packages to 2.x/site-packages? Do you install Python 2.x into a
> separate directory and grumble every time you have to change the #! line in
> your scripts?
I personally stopped using Redhat, but I recommend that you install
the Redhat-provided python2 binary. You could then install all
additional packages that you need - many of them should install easily
thanks to distutils.
HTH,
Martin
Roman Suzi
It's better to know if RedHat configuration tools can be run
under Python 2.x. Has anybody done any tests on this?
RedHat switched to bash2 at last (after 2 (or more?) major RedHat
versions!). Maybe Python2 is on their radar too.
As for me, I too find it inconvenient to manually handle
#!-lines, but rebuilding rpms by
python2 setup.py bdist_rpm
with
[bdist_rpm]
python=python2
in /root/.pydistutils.cfg usually helps.
(I only wish all Distutils-using packagers were aware that
Distutils could use RPM too)
And as for the subject, RedHat definitely helps Python.
Python 1.5.2 is stable and compact workhorse version.
> --
> - Tim Roberts, ti...@probo.com
> Providenza & Boekelheide, Inc.
>
Sincerely yours, Roman A.Suzi
--
- Petrozavodsk - Karelia - Russia - mailto:r...@onego.ru -
Richard Jones
The python.org python2 linux RPMs install just fine on redhat too.
Distutils makes installing packages a cinch - even to multiple python
installations (I have 1.5.2, 2.1.3 and 2.2.1 installed here, with most
packages installed in the latter two)
Richard
Erik Max Francis
> How have other people handled this? Do you just copy all of
> 1.52/site-packages to 2.x/site-packages? Do you install Python 2.x
> into a
> separate directory and grumble every time you have to change the #!
> line in
> your scripts? I tried updating all of the #! lines in the Red Hat
> scripts,
> but this, of course, blows as soon as you do an rpm upgrade of a
> Python-based package.
Install Python 2.x into /usr/local. If you want to be slick, put a
symlink in /usr/local/bin/python1.5 to /usr/bin/python. Now when you
write a script that requires 2.x, make the bangpath
/usr/local/bin/python2.2; when it requires, make it
/usr/local/bin/python1.5. When you don't care, use
/usr/local/bin/python, /usr/bin/python, or even /usr/bin/env python.
--
Erik Max Francis / m...@alcyone.com / http://www.alcyone.com/max/
__ San Jose, CA, US / 37 20 N 121 53 W / ICQ16063900 / &tSftDotIotE
/ \ Who'd ever think it / Such a squalid little ending
\__/ The American and Florence, _Chess_
Church / http://www.alcyone.com/pyos/church/
A lambda calculus explorer in Python.
Andrew McNamara
>administration activities. Ordinarily, I'd say this was a Good Thing for
>the betterment and furtherance of Python.
>
>However, it makes it deucedly difficult to upgrade away from 1.52. If one
>upgrades /usr/bin/python to be 2.x, all of Red Hat's custom configuration
>scripts are no longer found in site-packages.
RedHat should have installed a private copy of 1.5.2 for their
admin scripts and let the user choose which version they wanted as
/usr/bin/python.
RedHat, if you're listening, it's things like this that are going to
make me dump RedHat off my systems before long.
--
Andrew McNamara, Senior Developer, Object Craft
http://www.object-craft.com.au/
Oleg Broytmann
> It's also bogus to speak of Python 1.5.2 as some ancient dinosaur that
> should be dead and gone. It's just 2 years old or so.
Alas, in these days of software rush, 2 years are more than many people
can tolerate; for them, 2 years-old software has already dead and gone. Not
that I am saying it is good, but this is how many people think... or were
taught to think.
Oleg.
--
Oleg Broytmann http://phd.pp.ru/ p...@phd.pp.ru
Programmers don't die, they just GOSUB without RETURN.
James J. Besemer
Tim Roberts wrote:
> However, it makes it deucedly difficult to upgrade away from 1.52. If one
> upgrades /usr/bin/python to be 2.x, all of Red Hat's custom configuration
> scripts are no longer found in site-packages.
Not having 1.52 the standard breaks a lot of stuff.
I could not get the latest Mailman to install with "python=python1.2". All
sorts of "impossible" errors. Took me a hell of a long time to figure out it
was chaning the python default that caused all the problems.
> Do you install Python 2.x into a
> separate directory and grumble every time you have to change the #! line in
> your scripts?
Yup. I have separate complete installations of 1.5, 2.0 and now 2.1 and
explicitly refer to them. It sucks but as rapidly as new releases come out I
don't see a better way. I guess you only have to maintain your own scripts
pointing to the current release and whatever Linux wants. The intermediate
ones can be gotten rid of if/when you know they're no longer needed.
If it's just YOU -- that is your own private scripts not ones you make
generally available, you can setup your path to grab the proper version of
python. Then log in as somebody else to run the Linux sys admin stuff.
Regards
--jb
--
James J. Besemer 503-280-0838 voice
http://cascade-sys.com 503-280-0375 fax
mailto:j...@cascade-sys.com
Roy Smith
> Alas, in these days of software rush, 2 years are more than many people
> can tolerate; for them, 2 years-old software has already dead and gone. Not
> that I am saying it is good, but this is how many people think... or were
> taught to think.
*snort* Just yesterday at lunch, a co-workers asked me what I thought of
Apple's announcement that OS-9 was dead. Would it force me to upgrade to
OS-X before I really wanted to? My answer was that it really didn't affect
me because I hadn't upgraded to OS-9 yet.
Then again, I'm also running RedHat 6.2. Oddly enough, I've upgraded my
python to 2.x, and havn't yet seen any problems caused by that.
Emile van Sebille
> Alas, in these days of software rush, 2 years are more than many
people
> can tolerate; for them, 2 years-old software has already dead and
gone.
Yesterday while on-site implementing a new set of changes, I stumbled
across and modified a program link I'd originally written 22 years ago.
;-)
--
Emile van Sebille
em...@fenx.com
---------
Grant Edwards
> However, it makes it deucedly difficult to upgrade away from 1.52.
I've never had any problems. You can install the Python2
package from readhat, or you can do the normal install from
sources. Both worked fine for me. The former installs as
/usr/bin/python2 with libs in /usr/lib/python2.1. The latter
installs in /usr/local/.
> If one upgrades /usr/bin/python to be 2.x, all of Red Hat's
> custom configuration scripts are no longer found in
> site-packages.
Leave /usr/bin/python alone so that those scripts still run
1.5.2.
> How have other people handled this?
I usually install Python 2.x in /usr/local and put
/usr/local/bin before /usr/bin in my PATH. Then I do
#!/usr/bin/env python
In my scripts.
--
Grant Edwards grante Yow! Have my two-tone,
at 1958 Nash METRO brought
visi.com around...
Mark Charsley
(Tim Roberts) wrote:
> Red Hat 7.x uses Python 1.52 for many of its configuration and
> administration activities. Ordinarily, I'd say this was a Good Thing
> for
> the betterment and furtherance of Python.
>
> However, it makes it deucedly difficult to upgrade away from 1.52. If
> one
> upgrades /usr/bin/python to be 2.x, all of Red Hat's custom
> configuration
> scripts are no longer found in site-packages.
Not being an expert in linux (let alone RH), wouldn't it be reasonably
simple to have /usr/bin/python be a tiny little app that does the
following?
if (input_script_is_in_a_RH_directory)
{
start_and_transfer_cmd_line_inputs_outputs_etc(Python1.5);
}
else
{
start_and_transfer_cmd_line_inputs_outputs_etc(Python2);
}
--
Mark - personal opinion only, could well be wrong, not representing
company, don't sue us etc. etc.
Noah Spurrier
Ha! RedHat 6.2 was better known as RootHack 6.2.
Oh well, it taught me a lot about security -- the hard way.
Yours,
Noah
Erno Kuusela
Spurrier" <no...@noah.org> writes:
| Ha! RedHat 6.2 was better known as RootHack 6.2.
| Oh well, it taught me a lot about security -- the hard way.
not much different than other platforms as far as i know,
unfortunately. if you put a computer with in a potentially hostile
environment and run servers, you need to follow incoming security
updates and apply them diligently. read bugtraq sometime and weep.
-- erno
Christian Tanzer
> It's also bogus to speak of Python 1.5.2 as some ancient dinosaur that
> should be dead and gone. It's just 2 years old or so.
You are just slightly off. 1.5.2 was released more than three years
ago and was superseded by a newer Python almost 2 years ago.
> It's an error to needlessly break compatibility with it.
And it's FUD to claim needless compatibility breaks have happened.
> I don't think it's a fair question. Red Hat is just another Python user
> and the implied criticism of them for using 1.5.2 is unreasonable.
> 1.5.2 was the latest and greatest Python version when the Red Hat 7.x
> series began, and per perfectly reasobale policy,
Do I understand you correctly in that it was perfectly reasonable for
Red Hat to first ship a broken gcc and then change to a newer one
during the 7.x series?
I doubt anybody would care which Python version Red Hat uses for their
tools if they didn't make it unreasonably difficult for their users to
use a current Python version for non-Red Hat purposes.
--
Christian Tanzer tan...@swing.co.at
Glasauergasse 32 Tel: +43 1 876 62 36
A-1130 Vienna, Austria Fax: +43 1 877 66 92
Paul Boddie
> Tim Roberts wrote:
>
> > Do you install Python 2.x into a
> > separate directory and grumble every time you have to change the #! line in
> > your scripts?
No, this is a pretty inconvenient way of solving the problem. See
below...
> If it's just YOU -- that is your own private scripts not ones you make
> generally available, you can setup your path to grab the proper version of
> python. Then log in as somebody else to run the Linux sys admin stuff.
Well, since the only user who can run the sysadmin stuff (or who is
likely to do so) is 'root', then I would suggest setting up paths for
other users which do indeed point to more recent Python versions. In
fact, that's what I do...
http://webware.colorstudy.net/twiki/bin/view/Webware/PythonVersionConflicts
Linux is a multi-user operating system after all.
Paul
Grant Edwards
> I doubt anybody would care which Python version Red Hat uses
> for their tools if they didn't make it unreasonably difficult
> for their users to use a current Python version for non-Red Hat
> purposes.
They don't make it the least bit difficult. I've never had any
problems using either the Python2 package from RH or
from-scratch installs of Python 2.x. I agree that it would be
nice if they put 1.5.2 in as a "private" install and have 2.x
as /usr/bin/python, but dealing the existing setup isn't
difficult.
--
Grant Edwards grante Yow! Hand me a pair of
at leather pants and a CASIO
visi.com keyboard -- I'm living
for today!
Erik Max Francis
> I usually install Python 2.x in /usr/local and put
> /usr/local/bin before /usr/bin in my PATH. Then I do
>
> #!/usr/bin/env python
>
> In my scripts.
Note that relying on /usr/bin/env is not always the best solution.
First, on some weird platforms, env isn't in /usr/bin; and second, env
relies on your PATH, which can be different under varying circumstances
-- for instance, if you relied on env to find a custom installed python
under /usr/local, a cron job running a Python script using env would
find the wrong one, since /usr/local/bin is not in the PATH of a cron
job.
Geoff Gerrietts
> How have other people handled this? Do you just copy all of
> 1.52/site-packages to 2.x/site-packages? Do you install Python 2.x into a
> separate directory and grumble every time you have to change the #! line in
> your scripts? I tried updating all of the #! lines in the Red Hat scripts,
> but this, of course, blows as soon as you do an rpm upgrade of a
> Python-based package.
Yes, it's sloppy deployment on RedHat's part. I'm sure the guy who put
together the system is suitably embarassed by his/her own oversight,
or should be. It's proven to be a real problem for more than one
person.
In solving the problem, I've gone both ways. I like the PATH solution
some suggest, it interests me. But I tend to shy away from solutions
that rely on the operating environment of a process to resolve
correctly, because the environment tends to be so highly dynamic and
somewhat hard to predict. I also dislike adding external dependencies
to a program -- that's something the free software community tends to
do quite a bit, and often to frustrating or infuriating result.
The other options I've aimed at are outlined in an older post of mine:
http://groups.google.com/groups?selm=mailman.1017695170.25885.python-list%40python.org
Others in that thread contributed other equally or more interesting
opinions.
Luck,
--G.
--
Geoff Gerrietts <geoff at gerrietts dot net> http://www.gerrietts.net/
"Politics, as a practice, whatever its professions, has always been the
systematic organization of hatreds." --Henry Adams
John Baxter
Tim Roberts <ti...@probo.com> wrote:
> Red Hat 7.x uses Python 1.52 for many of its configuration and
> administration activities. Ordinarily, I'd say this was a Good Thing for
> the betterment and furtherance of Python.
On balance it is, despite the 1.5.2-ishness.
>
> However, it makes it deucedly difficult to upgrade away from 1.52. If one
> upgrades /usr/bin/python to be 2.x, all of Red Hat's custom configuration
> scripts are no longer found in site-packages.
>
> How have other people handled this? Do you just copy all of
> 1.52/site-packages to 2.x/site-packages? Do you install Python 2.x into a
> separate directory and grumble every time you have to change the #! line in
> your scripts? I tried updating all of the #! lines in the Red Hat scripts,
> but this, of course, blows as soon as you do an rpm upgrade of a
> Python-based package.
1. Leave Python 1.5.2 alone as Red Hat ships it. Leave the command
name python pointing to 1.5.2
2. Install Python (whatever) "beside" 1.5.2.
3. Develop some convention for the command name...we're using #! lines
like
#!/usr/bin/env python-historic
to get 1.5.2
and
#!/usr/bin/env python-preferred
to get our current Python-of-Choice
(We'll probably have to invent python-future or python-next or something
sooner or later.)
(Things are placed so that env finds what it should find even with the
minimal PATH from cron...and we don't run anything which doesn't have
/usr/bin/env, but not because of that lack. Won't work for people who
can't say that.)
This won't be fixed in RedHat until they decide to call something Red
Hat 8 (which I hope goes better than 7.0 did). They didn't upgrade at
7.0 time because they had used the rand module without having noticed
that it was deprecated when they used it, so its lack broke their tools.
Sigh! But by now RH would have an old Python even if they had gone with
what was current.
--John
Harry George
I think this has been discussed previously. Here is my approach:
1. Do absolutely nothing to the py1.5.2 installation or the RH
scripts. Leave it exactly as is.
2. In your .bashrc (or equiv), put in:
unset PYTHONHOME PYTHONPATH
This keeps the RH defaults from pushing you into using 1.5.2
libraries.
3. Install py2.1, py2.2, etc in /usr/local. Call all your own scripts
with these binaries (either on the #! line or on the commandline).
The binary will look for PYTHONHOME and PYTHONPATH, not find them,
and will go with its defaults. This way you can have several
versions installed and operational at the same time.
4. If you need to force some paths, make a script, e.g. "py22" which
does:
#!/bin/sh
export PYTHONHOME=my_special_place
/usr/local/bin/python2.2 "$@"
Call this as "py22"
--
Harry George
hgg...@seanet.com
John Baxter
Roman Suzi <r...@onego.ru> wrote:
> It's better to know if RedHat configuration tools can be run
> under Python 2.x. Has anybody done any tests on this?
Not without the rand module, for those tools which use it.
Most of the tools break badly under 2.x
Even some things that don't feel like tools, such as printing, broke in
some RH releases if python didn't mean 1.5.2 (I didn't care much, so I
couldn't print for several weeks once on the Linux "side" of the
laptop...then a chance message in a mailing list fixed the printing
problem for me). I think printing in recent RH has now changed enough
that this issue is gone.
--John
John Baxter
Andrew McNamara <and...@object-craft.com.au> wrote:
> RedHat, if you're listening, it's things like this that are going to
> make me dump RedHat off my systems before long.
In my case, it's things like bogus compiler versions. The Python is
livable, in many different ways. The compiler caused me to go back to
6.2 for quite a while on my laptop, and kept the company from using 7.0
at all (the boss also backed 7.0 off his laptop).
--John
Paul Rubin
> > It's also bogus to speak of Python 1.5.2 as some ancient dinosaur that
> > should be dead and gone. It's just 2 years old or so.
>
> You are just slightly off. 1.5.2 was released more than three years
> ago and was superseded by a newer Python almost 2 years ago.
OK, it was still current when Red Hat 7.0 came out though.
> > It's an error to needlessly break compatibility with it.
>
> And it's FUD to claim needless compatibility breaks have happened.
How is it FUD? Are you saying the compatibility breaks were needed?
If not, they were needless.
Jeremy Bowers
> Not without the rand module, for those tools which use it.
What RedHat admin tool uses rand?!?!?!? And doesn't that explain a lot...
"You have chosen to install a new printer. You roll a 1d20... You get a
1. *CRITICAL FAILURE* Your home directory is now being deleted."
Rob Brown-Bayliss
> Most of the tools break badly under 2.x
What I do is have a couple of scripts in /root.
My /usr/bin/python is alink, the scripts swap it to point to 1.5 or 2.x
I seldom reboot so when I do I swap the link to 1.5 and restart lpd then
swap it back to 2.x
Not great, and I could do it in the init scripts at boot time to save
the hassel, but it's a home machine that runs 24/7 so who cares.
--
R Brown-Bayliss
---====<=>=====---
http://zoism.org
Christian Tanzer
Paul Rubin <phr-n...@nightsong.com> wrote:
There were a few breakages between 1.5.2 and 2.x. IMHO, none were
gratuitous.
But you continue to rant about breakages without supplying any
evidence of where it really mattered to you. In particular, IIRC you
always talk about breaks where the code was made consistent with the
documentation (e.g., list.append) or an obsolete module was removed
(e.g., rand). I don't consider such issues `needless`. If you really
want to use a language with lots of accumulated cruft you probably
know where to find one.
OTOH, Many Python users were pleasantly surprised that they weren't
hit by any major issues. You obviously never migrated from Perl 4 to 5
<wink>.
Citing Red Hat to argue about compatibility breaks doesn't lend weight
to your argument either, considering how they messed around with gcc.
Erik Max Francis
> But you continue to rant about breakages without supplying any
> evidence of where it really mattered to you. In particular, IIRC you
> always talk about breaks where the code was made consistent with the
> documentation (e.g., list.append) or an obsolete module was removed
> (e.g., rand).
Another example of the former -- and the only "breakage" that affected
me in any way -- was that arguments which took socket addresses as
arguments allowed two arguments instead of a 2-tuple. And I knew about
that when I upgraded, so fixed it within moments.
Sean Reifschneider
>2. Install Python (whatever) "beside" 1.5.2.
The RPMs available from python.org install Python 2.2 as
"/usr/bin/python2". This works well for me. Of course, it does mean that
if you want to have functionality available for both Pythons you have to
install them in both locations...
>This won't be fixed in RedHat until they decide to call something Red
>Hat 8 (which I hope goes better than 7.0 did). They didn't upgrade at
>7.0 time because they had used the rand module without having noticed
Hah. Lest you forget, it wasn't 7.0 that was bad, it was 7.1... 7.1
happened when a lot of publicity was going on with Red Hat (the company),
and I think they kind of pushed it out. For KRUD, our Red Hat based
distribution, it was nearly 6 months before we felt the errata had brought
it up to a point where we could update to 7.1. 7.0 wasn't anywhere near as
bad...
Sean
--
Fire at the celuloud factory. No film at eleven.
-- _Kentucky_Fried_Movie_
Sean Reifschneider, Inimitably Superfluous <ja...@tummy.com>
tummy.com - Linux Consulting since 1995. Qmail, KRUD, Firewalls, Python
Sean Reifschneider
>You are just slightly off. 1.5.2 was released more than three years
>ago and was superseded by a newer Python almost 2 years ago.
Red Hat has a policy that they won't do a major number upgrade within a
major number of their distro. So, going from Red Hat 7.2 to 7.3 won't
produce an upgrade of Python from 1.5.3 to 2.2.1...
>Do I understand you correctly in that it was perfectly reasonable for
>Red Hat to first ship a broken gcc and then change to a newer one
>during the 7.x series?
It apparently fit into their upgrade policy... My understanding, from
listening to C++ programmers who were really following the issue, is that
the push to that "broken" compiler (which compiled without problem all
the extras we were shipping, BTW) was really necessary because the previous
compiler was also broken for normal use... Dealing with things like
templates and the like...
>I doubt anybody would care which Python version Red Hat uses for their
>tools if they didn't make it unreasonably difficult for their users to
>use a current Python version for non-Red Hat purposes.
It doesn't seem unreasonably difficult to use Python 2.x on Red Hat 7.x
boxes. You pick up the RPMs from python.org and install them... Or
(shameless plug), you buy KRUD which installs Python 2.2.1 as part of a
normal Red Hat-based install...
Sean
--
"All I'm saying is that when I'm around you I find myself showing off,
which is the idiots version of being interesting." -- _LA_Story_
Mike Brenner
Just curious: How many minutes, nay how many seconds, did it take the Python community to ship Red Hat a Python 1.7 release that happens to be identical to Python 2.2.1, except the label on the CD?
Christian Tanzer
Sean Reifschneider <ja...@tummy.com> wrote:
> >Do I understand you correctly in that it was perfectly reasonable for
> >Red Hat to first ship a broken gcc and then change to a newer one
> >during the 7.x series?
>
> It apparently fit into their upgrade policy... My understanding, from
> listening to C++ programmers who were really following the issue, is that
> the push to that "broken" compiler (which compiled without problem all
> the extras we were shipping, BTW) was really necessary because the previous
> compiler was also broken for normal use... Dealing with things like
> templates and the like...
The compiler they shipped generated a lot of question why Python was
"broken".
In such a case, it would seem reasonable to ship a standard gcc for
normal use and an experimental gcc for the C++ programmers interested
in templates and stuff.
> >I doubt anybody would care which Python version Red Hat uses for their
> >tools if they didn't make it unreasonably difficult for their users to
> >use a current Python version for non-Red Hat purposes.
>
> It doesn't seem unreasonably difficult to use Python 2.x on Red Hat 7.x
> boxes. You pick up the RPMs from python.org and install them...
IMHO, the distribution should not force a specific Python version to
be the default. I.e., having /usr/bin/python point to 2.x should not
break any number of Red Hat utilities. Forcing the user to specify a
Python version in the #! line or on the command line sucks.
> Or (shameless plug), you buy KRUD which installs Python 2.2.1 as part
> of a normal Red Hat-based install...
I'd rather continue to use Debian, thank you.
Sean Reifschneider
>Just curious: How many minutes, nay how many seconds, did it take the
>Python community to ship Red Hat a Python 1.7 release that happens to
>be identical to Python 2.2.1, except the label on the CD?
A minor number release, like going from 1.6 to 1.7 should not, according to
Python standards, cause existing 1.x code to break. This convention is
part of the reason that Red Hat only does minor number updates in their
minor number releases...
So, how long would it take for such a 1.7 release to be made by the Python
community? Forever, Guido would never bless it...
Sean
--
What we see depends on mainly what we look for.
-- John Lubbock
Sean Reifschneider
>The compiler they shipped generated a lot of question why Python was
>"broken".
Sure, and it was fixed quite quickly with errata... If you aren't applying
errata to your system, you have bigger problems than the compiler
complaining about some symbols during the Python build. IIRC, though, it
was actually glibc that was the issue (if you're thinking the symbol
undefined problem that I'm thinking of), not the compiler...
>In such a case, it would seem reasonable to ship a standard gcc for
>normal use and an experimental gcc for the C++ programmers interested
>in templates and stuff.
Interestingly, they did... The older compiler was called "kgcc"...
>IMHO, the distribution should not force a specific Python version to
>be the default. I.e., having /usr/bin/python point to 2.x should not
>break any number of Red Hat utilities. Forcing the user to specify a
>Python version in the #! line or on the command line sucks.
Yeah, in a perfect world people would write code that anticipated any
problems that future releases of the language might cause... When you
figure out how to do this, go ahead an submit a patch to Red Hat...
Sean
--
Sometimes it pays to stay in bed on Monday, rather than spending the rest
of the week debugging Monday's code. -- Christopher Thompson
Cliff Wells
Sean Reifschneider wrote:
> On Sun, May 12, 2002 at 10:12:35AM +0200, Christian Tanzer wrote:
> >IMHO, the distribution should not force a specific Python version to
> >be the default. I.e., having /usr/bin/python point to 2.x should not
> >break any number of Red Hat utilities. Forcing the user to specify a
> >Python version in the #! line or on the command line sucks.
>
> Yeah, in a perfect world people would write code that anticipated any
> problems that future releases of the language might cause... When you
> figure out how to do this, go ahead an submit a patch to Red Hat...
I think the better solution has been mentioned here several times: if Red Hat
is going to build utilities that require a certain version of Python (which is
not unreasonable) then they should have a special installation called
"python-rh" or something and use that rather than require users to name their
version "python2" or whatever.
Hopefully they will take this approach when 8.0 comes out.
--
Cliff Wells, Software Engineer
Logiplex Corporation (www.logiplex.net)
(503) 978-6726 x308 (800) 735-0555 x308
Charles Hixson
> ...
>
> Yeah, in a perfect world people would write code that anticipated any
> problems that future releases of the language might cause... When you
> figure out how to do this, go ahead an submit a patch to Red Hat...
>
> Sean
It's easy. Just install the python you want in /usr/local, and change
your *USER* path so that /usr/local is searched before /usr/bin.
Then as root, you can use the old version, and as the developer you can
use the one you compiled from CVS (or whichever other version you want).
And it you don't specify, you still reach the default install.
If you're tight on disk space, you can either put a link to python2 in
/usr/local, and have it be named python, or just use the old version.
(Sorry, limited disk space is a limit.)
--
-- Charles Hixson
Gnu software that is free,
The best is yet to be.