Re: [RFA] ignore PYTHONHOME environment variable.

[Joel Brobecker <brobecker at adacore dot com>]

> On Tue, 23 Nov 2010 18:30:54 +0100, Joel Brobecker wrote:
> # GDB_PYTHONHOME is something that got suggested by at least 2 people
> # (someone at AdaCore also suggested it a while back).
> 
> How many OS distributors have suggested it?  It is against the fundamental
> distro policies.  Many reasons why bundling is broken are at:
> 	http://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries

I would rather not go there, for 2 reasons:

  1. Either the change is useful, or it is not; If not, then it does not
     go in;

  2. OS distros have very different operational needs compared to tool
     providers such as ourselves.

> This is a classical example of a vendor distribution patch which is
> not expected to be present upstream.  Still I can override these
> downstream; just I believe upstream should not contain any sych
> directory hacks.

I think that this is too general a criticism. I care more about
the FSF tree than I care about the AdaCore one, and I would not have
proposed this change if I thought that it would not be useful to other
people.

I understand that you don't like the patch, and I get the fact that
I don't seem to have changed my opinion much.  I assure you that
I will not press much further if the change of behavior does not
get either your approval or more general support from the other
maintainers.

> Still $PYTHONHOME should apply for GDB, the same way as it applies for
> any other package.  It is also the reason it exists.  One may want to override
> system Python installation in $HOME, with proper $LD_LIBRARY_PATH and
> $PYTHONHOME I hope it should work well, as it works for other software.
> Your proposed way the user would have to troubleshoot (s)he needs to set also
> $GDB_PYTHONHOME, besides $PYTHONHOME.

Please consider also the situation where the user sets PYTHONHOME to
a version of Python that is incompatible with the one we used to build
GDB, and then miserably crashes with no hint as to what the problem
might be.  This is what happened in my case, and the users had no clue
why GDB just crashed.

This may never happen in your context, because you control the entire
distro.  But some users install third-party code which they sometimes
compiled themselves, and then install it on the side.  Even outside
of AdaCore, I do it all the time (Eg: tools of specific versions that
I need for GDB development, or externally-provided binaries). I don't
install them in /usr or /usr/local because I want to be able to wipe
them anytime I want by a simple "rm -rf".

I tried to find other ways to find a compromise, and always end up
going back to the same principle: We simply cannot trust PYTHONHOME
to point to a version of Python that's compatible with the version
we used at build time. PYTHONHOME is for the Python executable. We
must try to use the Python library that we used to build GDB. And on
the rare cases that someone has its own Python library, and actually
wants GDB to use it, and knows that it's compatible, I can add
a GDB_PYTHON_PATH environment variable.

That way, GDB always behaves the same, regardless of how it's been
built. I think that this is a lot less confusing than having
configure-time switches that dramatically modify the behavior
in a way that is not necessarily obvious. KISS.

What we can also do is warn users when we see that PYTHONHOME is
defined and not GDB_PYTHON_HOME.  That way, they are not surprised
when that happens, and they get a helpful indication of how to
remedy the problem.  Maybe we can also introduce a command-line
switch that triggers one type of behavior or the other, but I think
we're getting in the overkill range.

> #define GDB_DATADIR_RELOCATABLE 1
> #define PYTHONDIR "/usr/share/gdb/python"
> #define PYTHON_PATH_RELOCATABLE 1
> #define WITH_PYTHON_PATH "/usr"
> 
> Which also seems broken, though - why should system GDB use Python
> directories depending on where the gdb binary is located?  I
> apparently missed the patch.

I don't know if the rest of the GNU tools make an exception for /usr
and /usr/local, or not.  But having your dependencies be relocatable
is a widespread practice that is extremely convenient (think of prefix.o
in the compiler, for instance, which allows me to copy a compiler
install at a different location). I think that the same convenience
is equally useful for tools installed in system locations such as /usr.

-- 
Joel