Installing Python upgrade

[chzlchp]

I wish to upgrade my Python package (in my Mandrake 10.1) to '2.4.1' from the '2.3.4' that came with the distro.

A few niggling details have me nervous...to wit: where should I effect the new installation? The standard 'hash/bang' line I use in my scripts is:

#!/usr/bin/python

In the above referenced directory (/usr/bin) I have two executables, 'python*' and 'python2.3*'. Should I therefor move the downloaded .tgz file over to '/usr/bin' and do the 'unpacking, etc.' over there? Then, anticipating this glitch, will the 'system' automatically choose the newer update when I invoke 'python', or should I somehow disable the predecessors?

[je_fro]

there's no way I'd move the tarball and unpack it in /usr/bin. You should do it in your home directory first and read the README and INSTALL files for further instructions. Blindly installing without reading the docs is a great way to hose your system.
:D

[chzlchp]

there's no way I'd move the tarball and unpack it in /usr/bin. You should do it in your home directory first and read the README and INSTALL files for further instructions. Blindly installing without reading the docs is a great way to hose your system.
:D

Well...that's interesting.

Having tucked the tarball away in a dedicated file within my home directory, unpacking it produced:

drwxr-xr-x 17 lowell lowell 4096 Mar 30 2005 Tools/
drwxr-xr-x 5 lowell lowell 4096 Mar 30 2005 RISCOS/
drwxr-xr-x 2 lowell lowell 4096 Mar 30 2005 Python/
drwxr-xr-x 2 lowell lowell 4096 Mar 30 2005 Parser/
drwxr-xr-x 2 lowell lowell 4096 Mar 30 2005 PCbuild/
drwxr-xr-x 7 lowell lowell 4096 Mar 30 2005 PC/
drwxr-xr-x 2 lowell lowell 4096 Mar 30 2005 Objects/
drwxr-xr-x 4 lowell lowell 4096 Mar 30 2005 Modules/
drwxr-xr-x 3 lowell lowell 4096 Mar 30 2005 Misc/
drwxr-xr-x 10 lowell lowell 4096 Mar 30 2005 Mac/
drwxr-xr-x 37 lowell lowell 8192 Mar 30 2005 Lib/
drwxr-xr-x 2 lowell lowell 4096 Mar 30 2005 Include/
drwxr-xr-x 2 lowell lowell 4096 Mar 30 2005 Grammar/
drwxr-xr-x 22 lowell lowell 4096 Mar 30 2005 Doc/
drwxr-xr-x 23 lowell lowell 4096 Mar 30 2005 Demo/
-rw-r--r-- 1 lowell lowell 88451 Mar 28 2005 configure.in
-rwxr-xr-x 1 lowell lowell 592549 Mar 28 2005 configure*
-rw-r--r-- 1 lowell lowell 32401 Mar 28 2005 Makefile.pre.in
-rw-r--r-- 1 lowell lowell 13355 Mar 10 2005 LICENSE
-rw-r--r-- 1 lowell lowell 53490 Mar 9 2005 setup.py
-rw-r--r-- 1 lowell lowell 49761 Jan 25 2005 README
-rw-r--r-- 1 lowell lowell 24330 Oct 13 2004 pyconfig.h.in
-rw-r--r-- 1 lowell lowell 2110 Sep 27 2003 aclocal.m4
-rwxr-xr-x 1 lowell lowell 7122 Jun 14 2003 install-sh*

The documentation tells me that 'Makefile.pre.in' will be morphed into the proper 'make' file by running ./configure. Got too many questions to wade thru before jumping off that cliff, though.

Let us suppose that I did launch this upgrade in my ~/ directory. From a standpoint of user availability that's no problem. I alone suffer in front of the blazing monitor of this egregious edifice. But...would the systemwide 'rc' files still impose their wants on a python that now existed only within my home directory? (Worst case, I've got a ~/ backup CD that I made last night-just as a last resort.) Wading thru the list of directories (and README) I'm led to understand that this is fairly much a complete package. It contains all its' modules, and [I believe] I understand that Tkinter is included. It appears I would be happily back up and running much as before after a [local] installation.

Since the docs don't specifically advise me to 'go to thus-and-thus directory, and install there', I'm left with these muddy questions, and their implications.

[je_fro]

yeah, it looks like you can do ./configure --help to see a list of options available. then what I usually do is "make" and "make install". of course the install is unsuccessful because I usually do "./configure --prefix=/usr" and of course I don't have write permissions there....it's just to see what _would_ get installed. if it looks good then su and "make install".

[chzlchp]

there's no way I'd move the tarball and unpack it in /usr/bin. .
:D

Help me understand this concept a little better-with a helpful analogy. I'm getting ready to help my son install a new carburetor on his CJ-7. We darned sure are gonna bolt the new one on in exactly the same place the old one occupied. Why would I NOT, or...what would I risk...putting the new install of Python into the same spot that the old one occupies? Intuitively, that makes all the sense in the world to me.

[GliderMike]

You're not seeing where to put all the pieces and parts IN the carburetor. When you do "make install" it places all files in their proper directories, which could be many more than /usr/bin or a subdirectory thereof. (as well anything else the install needs to do). Highly recommend using make, then make install, OR, use a package manager if your distribution supports it (such as apt-get, or .rpm based tools).

I guess to better flesh out your analogy, your suggestion would be like putting the air filter on top of the engine without the rest of the carburetor, and all the while forgetting to even take the old carburetor off. Clearly that won't work to well.

[je_fro]

....or at least taking a LOOK at the carbuerator to see if it'll fit...

[chzlchp]

....or at least taking a LOOK at the carbuerator to see if it'll fit...

So, what's the moral of this tale? By what rules does one choose a particular place to install a package? What are the constraints that need to be understood?

[je_fro]

it depends on your distro...for me, --prefix=/usr is used on just about all packages. for you it might be /usr/local or you may want to put a particular package in /opt. the moral is to understand what you are doing, and where things will go when you do:
mv somepackage.tar.gz /usr/bin
cd /usr/bin
tar -zxvf somepackage.tar.gz

besides, it looks like with that python package you'll do "./configure --prefix=/usr && make && su && make install" and you don't really want to do that from /usr/bin, but rather from your home directory.

[chzlchp]

...for me, --prefix=/usr is used on just about all packages.

for you it might be /usr/local...the moral is to understand what you are doing...

So...I went to 'man prefix'; no such listing. I went to 'man tar'; never found any reference to '--prefix'. Maybe it's there, and I couldn't see it, but-I didn't.

May I subtly restate your second [edited] comment? Not, ...the moral; but, ...the dilemma is to understand what you are doing.

That's what I'm scratching here for-to try to understand; as usual, it's an uphill battle in the dark without even having a sense of where the first foothold might be. Like I might say to myself, "Self, let's put this tarball into '/usr/local', and blast it open!" And then I would say...uhmmm, why? On what basis would I brilliantly and suddenly decide that, YES, I must put this into /usr/local?! What would lead me to that conclusion?

That's my whole point and frustration. It seems there are so many dots missing in the connections from A to B and so on. Ok, I'll put this particular file in such-and-such, and tweedle it. Uhmm...why? Well, 'cause some guy said to. Got any idea in the world why he said so? Uhmm...no. Anywhere I can look to find out why? Uhmm...dunno. If file such-n-such is A, how can I connect it to procedure B? Uhmm...dunno. And so, the circle of frustration continues.

[je_fro]

You don't really ever "put this tarball into '/usr/local', and blast it open". Tarballs are usually source code and the various scripts used to compile and install it. When you compile from source, you run the ./configure script. (it's usually in the top level dir of the tarball - ./configure --help to see all the available options, including --prefix) this can be done anywhere, preferably your home dir. Then you run make and (su) make install. The last step installs binaries and libs and whatever else, under the prefix. WIth ./configure --prefix=/usr this would be /usr/bin and /usr/lib, etc... You can then delete the source package if you want, but most keep it around in case they ever want to do a "make uninstall".
Anyway, all this can be avoided if you use your distros package management utilities.

[GliderMike]

How about a Winblows analogy to try and help? If you say, download a program that is in a .zip archive, you wouldn't want to move that .zip to "Program Files" and unzip it there, you are likely going to put the .zip somewhere else "c:\windows\temp" perhaps? or "mydir\downloads" perhaps and unzip it there. Then you have to install it. In Windows that would be done normally by running setup.exe or some such. Setup.exe will then install all of the files in the proper directories, some .DLLs in the right spot, some .exe in "program files\whateverprogram".

What we're talking about is the equivalent of taking the .zip file (in this case, .tar.gz) and putting in some temporary location. It doesn't matter where, because it's really only files that will be used temporarily until the program is installed.

So, take your whatever.tar.gz and put it somewhere temporary. Now, the only difference here is that instead of running setup.exe, we first need to make the executables and libraries. We do this by configuring (./configure) and compiling (make) if we are starting from source. After make completes successfully now we need to do the equivalent of running setup.exe, we do that by running "make install". Running make install will do the same job that setup.exe does on windows, puts all of the libraries and executables in the proper place. If you are really anal you can massage where there go, usually it puts them all in a workable place so you don't need to worry about it.

Assuming no errors, bam, you're done and ready to use the program.

So to recap with winblows analogy parts first (linux parts in paren) when applicable:

1) Download .zip file (usually .tar.gz in Linux world) Save it in or copy to temporary location (I like to use /tmp personally, opinions will vary).

2) go to temp location and "unzip it". (run tar -xzvf file.tar.gz)
3) (change to newly created directory from extracting "unzipping")
4) (do ./configure) -- this ensures depedencies are met and it's ready to compile.
5) make (turn source code into real files, executables and libraries)
6) run setup.exe (run "make install')
7) use program. Do whatever you want to with files that you originially "unzipped" (extracted with tar -xzvf file.tar.gz). You don't need them anymore.

Hope this sheds some light on it. Forgive typos, etc, I've been painting the damn house all day and my wife just said dinner is here so I'm hurrying.

Mike