Python 2.3.2 RPM's for Redhat 8.0 or Python source RPM and upgrade procedure?

Python 2.3.2 RPM's for Redhat 8.0 or Python source RPM and upgrade procedure?

Post by Scott Chap » Sun, 05 Oct 2003 02:43:31


Does anynone have these available? I'd like to upgrade (hoping it doesn't
break my Redhat install).

If I upgrade, all my site-packages have to be reinstalled to the new
site-packages directory right?

Scott
 
 
 

Python 2.3.2 RPM's for Redhat 8.0 or Python source RPM and upgrade procedure?

Post by Skip Monta » Sun, 05 Oct 2003 03:01:19


Scott> Does anynone have these available? I'd like to upgrade (hoping
Scott> it doesn't break my Redhat install).

Sean Reifschneider builts them as a service to the community. I suspect it
will be a few days to a week before he releases 2.3.2 RPMs.

Scott> If I upgrade, all my site-packages have to be reinstalled to the
Scott> new site-packages directory right?

No, the installation will go to (I think) /usr/local/lib/python2.3 or
/usr/lib/python2.3. The site-packages directory will thus remain the same.

Skip

 
 
 

Python 2.3.2 RPM's for Redhat 8.0 or Python source RPM and upgrade procedure?

Post by Scott Chap » Sun, 05 Oct 2003 04:01:21


Thanks for the info. I'll wait around.


Just an FYI, RedHat probably has things rather customized here. The original
Python install put the site-packages directory in /usr/lib/python2.2/. I
expect the upgraded RPM installs to follow suit but I don't know if Sean
Reifschneider's RPM's do or not.

Could I move the site-packages directory manually?

Does the entire site-packages contents need to be rebuilt (or reinstalled)
with the new Python or will it automatically do so (I mean the .pyc files).
Do I need to manually remove all the byte-compiled files?

Thanks for the help!
Scott
 
 
 

Python 2.3.2 RPM's for Redhat 8.0 or Python source RPM and upgrade procedure?

Post by Skip Monta » Sun, 05 Oct 2003 04:15:41


>> No, the installation will go to (I think) /usr/local/lib/python2.3 or
>> /usr/lib/python2.3. The site-packages directory will thus remain the
>> same.

Scott> Just an FYI, RedHat probably has things rather customized here.
Scott> The original Python install put the site-packages directory in
Scott> /usr/lib/python2.2/. I expect the upgraded RPM installs to follow
Scott> suit but I don't know if Sean Reifschneider's RPM's do or not.

My mistake. I thought you wanted to upgrade from 2.3.

Scott> Could I move the site-packages directory manually?

The result probably won't be pleasant if it contains any extension modules.
Also, Red Hat has a lot of their own stuff which may not have been tested on
2.3 yet. This might be your biggest barrier. At the very least you should
probably leave 2.2 in place and leave /usr/bin/python as a link to
/usr/bin/python2.2 until you've had a chance to test some of their more
important system administration apps with 2.3 (like up2date).

Scott> Does the entire site-packages contents need to be rebuilt (or
Scott> reinstalled) with the new Python or will it automatically do so
Scott> (I mean the .pyc files). Do I need to manually remove all the
Scott> byte-compiled files?

At the very least I suggest you delete any .pyc or .pyo files. You can then
just execute the Lib/compileall.py script to recompile everything.

Skip
 
 
 

Python 2.3.2 RPM's for Redhat 8.0 or Python source RPM and upgrade procedure?

Post by Scott Chap » Sun, 05 Oct 2003 06:46:41


<snip>

Peter Hansen said in his post:

The non-pure Python stuff might break. It would be very NICE for the
Lib/compileall.py (for example) to tell you which things need further
attention but I don't know if that information is available to a script.

<rant>
Upgrading seems to ALWAYS be painful with these scripting languages. Perl is
no better. I'd like to see Python beat Perl out in this arena (some friendly
competition, huh? Where the end user benefits! :-) I'm running RedHat so
their dependency on Python is a mixed blessing also.

We, end users who are just getting into Python, look at this as something that
should be "seamless" when in actuality it's a major change to upgrade a
programming language environment that you have lots of dependencies around.
This change should be properly orchestrated and tested and it's probably a
bit naive to expect it to be seamless like a simple one-off.
</rant>

So the best advice is to figure out which all extension modules I have
installed manually and download new versions and install them?

Scott
 
 
 

Python 2.3.2 RPM's for Redhat 8.0 or Python source RPM and upgrade procedure?

Post by Skip Monta » Sun, 05 Oct 2003 07:35:23


Scott> Upgrading seems to ALWAYS be painful with these scripting
Scott> languages. Perl is no better. I'd like to see Python beat Perl
Scott> out in this arena (some friendly competition, huh? Where the end
Scott> user benefits! :-) I'm running RedHat so their dependency on
Scott> Python is a mixed blessing also.

Scott> We, end users who are just getting into Python, look at this as
Scott> something that should be "seamless" when in actuality it's a
Scott> major change to upgrade a programming language environment that
Scott> you have lots of dependencies around. This change should be
Scott> properly orchestrated and tested and it's probably a bit naive to
Scott> expect it to be seamless like a simple one-off.

The problem is, there are lots of dependencies we (the people twisting the
knobs on the Python distribution) really can't control. On my Mac I have
four different versions of Python: /usr/bin/python comes from Apple.
/sw/bin/python comes from fink. /usr/local/bin/python and
~/local/bin/python are my doing. I have no trouble with any of this for a
simple reason: I have my path jiggered to see ~/local/bin before anything
else, so I never run the versions Apple or fink installed, and I don't mess
with their stuff. On the rare occasions where I explicitly want to run one
of the other versions, I just use a full path. I think that's the best way
to do it on a Red Hat system as well (that's what I do on Mandrake, a Red
Hat derivative that seems to have eschewed Python for Perl). It wastes a
little disk space but is much less likely to create heartburn for Red Hat's
tools or worse, leave you with a system on which you can't perform routine
administrative tasks or update.

Similarly, on many systems you can choose a vendor provided X (where X might
be a C compiler, database library or jukebox application). If you want to
use a different version of those tools, you'd probably install them
somewhere different instead of overwriting the versions the vendor provides.
Replacing /usr/lib/libdb* with a later version of Sleepycat's library is a
sure-fire way to break your system in odd ways. Scripting languages are no
different in this regard. Wipe out what the vendor delivered at your own
peril.

Skip
 
 
 

Python 2.3.2 RPM's for Redhat 8.0 or Python source RPM and upgrade procedure?

Post by Cliff Well » Mon, 06 Oct 2003 03:23:51


IMO, the *best* solution would be for Redhat and other vendors to keep a
"system" version of Python separate for their own needs, e.g
/usr/bin/python-rh could link to their 2.2 install with all of its
modules. All their scripts could start with #!/usr/bin/python-rh and
problem solved. Some might think that this is a waste of disk space,
but anyone concerned about ~10MB of disk storage shouldn't be upgrading
functional software anyway.


Indeed. Although I strongly suspect that if one could discover all the
Python 2.2 dependencies and recompile them against 2.3 they would work
fine. Finding and rebuilding the dependencies is the real problem. It
seems odd that there's no 'rpm -q --what-depends' type command, since
'rpm -e python' will demonstrate that it clearly knows.

RPM is your fair-weather-friend.


Cliff

--
Now the sugar in your soft voice
Makes the sweetness in your weeping
-Swans
 
 
 

Python 2.3.2 RPM's for Redhat 8.0 or Python source RPM and upgrade procedure?

Post by Skip Monta » Wed, 08 Oct 2003 11:00:13


>> On my Mac I have four different versions of Python: /usr/bin/python
>> comes from Apple. /sw/bin/python comes from fink.
>> /usr/local/bin/python and ~/local/bin/python are my doing. I have no
>> trouble with any of this for a simple reason: I have my path jiggered
>> to see ~/local/bin before anything else, so I never run the versions
>> Apple or fink installed, and I don't mess with their stuff.

Cliff> IMO, the *best* solution would be for Redhat and other vendors to
Cliff> keep a "system" version of Python separate for their own needs,
Cliff> e.g /usr/bin/python-rh could link to their 2.2 install with all
Cliff> of its modules.

I think this is one of those "slippery slopes". Taken to its logical
conclusion, vendors would have to provide "system" versions of bash, Perl,
GCC, glibc, ... just to ensure that users could overwrite vendor-provided
tools. The simpler solution is to allow users to install their own copies
of various tools in non-system directories (/usr/local, /sw, ~/local, ...).

While I appreciate Sean's efforts to provide Python RPMs, they are
definitely a two-edged sword which can cut the unwary.

Skip
 
 
 

Python 2.3.2 RPM's for Redhat 8.0 or Python source RPM and upgrade procedure?

Post by Cliff Well » Tue, 14 Oct 2003 14:32:03


And taking things to their logical conclusion is often a slippery slope
of its own. Programmers have a way of thinking that finds pure
consistency more appealing than practical application. While I don't
entirely disagree you that there is a danger, I would suggest that when
a commonly used package (such as Python) is so central to the operation
of vendor supplied packages that upgrading it is nearly impossible, that
the vendor should keep their own copy. Do perl, bash, et al fall into
this category? I don't know, but I've never had a problem upgrading
them, while upgrading Python on Redhat is a royal pain. This suggests
to me that perhaps Redhat should maintain their own installation of
Python with a different name.


But the downside of this is when a user installs some package, say
boa-constructor and wants it to use the user-supplied version of Python,
then they must edit the shebang line in every relevant file.

To be certain, probably the real problem is the packaging system, which
is unable to provide enough information to make upgrading a reasonable
task. If rpm were able to give a list of packages that relied on
Python, then it would be a straightforward, if tedious, process for the
user to obtain the source rpms for said packages and rebuild them
against a newer version of Python.


Cliff

--
Someone shot nostalgia in the back, someone shot our innocence
-Bauhaus
 
 
 

Python 2.3.2 RPM's for Redhat 8.0 or Python source RPM and upgrade procedure?

Post by paul » Tue, 14 Oct 2003 22:03:16


With "complete" Red Hat installations weighing in at 4GB, I think Red
Hat could easily slip their own installation of Python in there
without anyone noticing.


I don't agree with this, but then by installing from the source
distribution into /usr/local and by changing my PATH, I'm effectively
maintaining Red Hat's private Python installation for them.

Paul