Python installing on Debian

Ed Cogburn edcogburn at hotpop.com
Tue Mar 30 12:52:58 CEST 2004


Haim Ashkenazi wrote:
> Ryan Spencer wrote:
> 
> 
>>On Mon, 29 Mar 2004 03:43:25 +0200, Haim Ashkenazi wrote:
>>
>>
>>>It's a very bad idea to install self-compiled applications to the same
>>>prefix as the ones from original packages. this can breake many things on
>>>your computer. what you have now is a semi-broke python installation, and
>>>a package that tries to install itself every time you run apt-get but
>>>fails.
>>>
>>>I think your best chance to "clean" things would be to uninstall every
>>>python2.3 package on your system (see what happenes when you run 'apt-get
>>>remove --purge python2.3'). but make sure you understand what you're
>>>doing (e.g. do you really want to purge your zope installaion? do you
>>>have important stuff there, do you know how to restore it?). then if
>>>there's still stuff in /usr/lib/python2.3 and /usr/local/lib/python2.3
>>>check that they don't belong to any package (with dpkg -S filename) and
>>>remove them. also check if you have a python binary in /usr/local/bin and
>>>delete it. then re-install all the python2.3 packages. this of-course
>>>will make you lose all your self-compiled modules, so you'll have to
>>>re-compile them. this is a long and messy job, but you got yourself into
>>>this position. just make sure you understand what you're doing before
>>>your doing it.
>>>
>>>in the future I would recommend using the source from unstable to build a
>>>package if you want a version newer then the one that exist in testing.
>>>also use 'stow' when you're compiling sources. this will let you
>>>uninstall self-compiled application easilly.
>>>
>>>
>>>
>>>>Thanks a lot,
>>>
>>>good-luck (you'll need it) :(
>>
>>It actually needn't be that messy. dpkg --purge'ing will only remove the
>>package in question, whereas using a program such as debfoster and pruning
>>the selected target package will remove all it's associate dependencies
>>entirely eradicating it from your system, maybe leaving behind empty
>>configuration folders in your home directory, but there's no fret for
>>that those won't be taking up barely any space and you can always remove
>>them later.
> 
> in my system 'apt-get remove --purge python2.3' wants to remove 401
> packages. that's what I meant messy. you have to check that you didn't
> change any system configuration file for any of the packages. and as a
> rule, it's a good idea to understand what's you're doing. I've seen too
> many times people following instructions and then discovering that nothing
> works without knowing how to restore...


It seems apt has gotten so popular that everyone has forgotten about dpkg, 
which apt is built upon.  :)  Yes, apt-get follows dependencies in that way, 
which is why apt was created, to handle dependencies automatically.  In this 
case however, it may not be necessary to remove everything to restore python. 
   It makes sense to try the least painful remedy first.  If it were me, I 
would first try rebuilding the python .deb package from my system with 
dpkg-repack as a backup, then using 'dpkg --force-all --purge python2.3' to 
delete just the python interpreter itself, not any of the packages that depend 
on it.  Clean any python directories/files left behind (there sometimes is in 
places like /etc and /usr/lib, etc), then reinstall python2.3 using the .deb 
you created with dpkg-repack.  If that fails, then try downloading a 
guaranteed virgin copy of the .deb package and repeating again.  If that fails 
too, then you're forced to start purging other python-related things to figure 
out whats causing the problem.  My point is that when apt doesn't do what you 
need it to do, you can always fall back on dpkg.

In this case the problem is likely to be the OP partially overwrote Debian's 
python with his own custom compiled one, because I have seen that "import 
site" failure happen when I did this myself some time ago.  I wasn't even 
installing the compiled version, I just built it and manually transferred the 
shared libs and executable to /usr, but that was enough to break some of the 
written-in-python library files.  Moral of the story: don't mix standard and 
custom-built packages.  If you want to try a custom built one, completely 
deinstall the standard one first.





More information about the Python-list mailing list