Python installing on Debian

[Ryan Spencer]

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.

So, I'd say use debfoster and prune the python2.3 package. It won't be a
messy process at all. Just remember, when it prompts the package
python2.3, remember to push 'p' for prune, not 'n' for that 'n' (standing
for 'no') will do the same thing as dpkg --purge and simply remove the
package in question.

There is the beginning concern of when using debfoster it will inquire
about every single dpkg on your system (If I am correct, it should read
something alike the apt-cache which, even with manual installation of
dpkg's, still is written to, keeping a meticulous record of all dpkg's
on your system. If not the apt-cache, I know it's another file.) But once
you get past all the programs you want and don't want, it keeps the
remaining information in the /var/lib/debfoster/keepers file, which you
can always edit if you accidentilly kept something.

And also, I wouldn't say installing certain packages would break
much - although I wouldn't mark out the possibility of it happening in
unstable and testing, I sometimes forget constant recorrection I had to
go through. Possible replacement of certain library
files for applications, but that's also an issue of whether or not the
actual library file or application itself has issues, and that's a risk
you take in using unstable and testing. For example, I have an Nvidia
Geforce four and I would constantly have problems with glibc conflicting
with my video card. If you wander through the debian newsgroups you'll
notice many others have experienced the same problem, it's merely a
question of the glibc's lack of testing - which is why it's in the testing
phase of debian.

The underline is that testing and unstable are more for those that A)
Don't mind having sometimes broken packages in exchange for bleeding edge
software and B) Developers helping in the aid of testing out applications
and hopefully moving testing into it's 'stable' state if tested vigorously
enough.

Take Care,
~Ryan