separate shared libraries or different Linux/Unix

["Martin v. Löwis"]

> What, in your experiences, is a functionally elegant solution to
> installing 2.6 and 3 from source without breaking package dependencies
> on your favorite Linux/Unix flavor? Is compiling Python 2.6 and 3.0 on
> a *nix development machine and having it work seamlessly as simple as
> choosing a particular flavor or are there always going to be package
> juggling/mangling/pinning/managing issues affecting the other programs
> on the operating system? Is it as simple as choosing a flavor that is
> likely to have a Python 3 package available?

If your distribution provides neither Python 2.6 nor 3.0, then there
shouldn't be any package juggling/mangling/pinning/managing issues
when you build it yourself. Just install it in /usr/local, and be done.

If your distribution does provide those versions, don't build them
yourself at all - just use the distribution ones, and be done.

> Is there a way to make a copy of shared libraries ( under perhaps /usr/
> local/py2.6lib/ and /usr/local/py3lib/ ) so that I can use 2.6 and 3
> without causing package problems with other programs within my
> operating system?

You don't need to make copies of shared libraries. Just install
with a prefix of /usr/local, and there won't be any shared library
conflicts. If something invokes the "python" binary without explicit
path, and /usr/local/bin precedes /usr/bin in the path, then it will
pick up your Python interpreter. If you don't want it to, "make
altinstall" instead of "make install" for Python.

> If this seems like a good solution, where can I find
> more information about how to implement separate libraries inside the
> same OS as appropriate for Python?

There is not much information that you need. It Just Works.

> This might be the better solution
> than simply choosing a development flavor of *nix because I am going
> to want to install other Python libraries like numpy and matplotlib
> from source that might depend on other potentially incompatible shared
> libraries than either versions of Python or my Linux/Unix distro ( I
> have a feeling I am going to learn how to use ldconfig ).

Just don't even think of passing --enable-shared to Python's configure,
and it will all work fine, and you won't need to use ldconfig.

> I have a bit of experience with Debian Etch but I recently garbled my
> package management database while compiling the latest version of zlib
> for Python 2.6. ( why was I compiling and installing zlib from source?
> I was learning another lesson in patience and planning )

Installing *other* stuff (but Python) from source is something that you
should completely avoid. Instead of installing zlib, you should have
just installed Debian's zlib1g-dev package. Likewise for any other
header files that you will need. The libraries provided by Debian are
sufficient for building Python 2.6 with all extension modules (that
can possibly work on Linux).

Regards,
Martin