From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2475 invoked by alias); 14 Dec 2010 10:33:38 -0000 Received: (qmail 2382 invoked by uid 22791); 14 Dec 2010 10:33:36 -0000 X-SWARE-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 14 Dec 2010 10:33:29 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 157392BAB69; Tue, 14 Dec 2010 05:33:28 -0500 (EST) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id upyZqqPrh9t8; Tue, 14 Dec 2010 05:33:28 -0500 (EST) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 64F402BAB48; Tue, 14 Dec 2010 05:33:27 -0500 (EST) Received: by joel.gnat.com (Postfix, from userid 1000) id 5195A145B58; Tue, 14 Dec 2010 11:33:05 +0100 (CET) Date: Tue, 14 Dec 2010 10:33:00 -0000 From: Joel Brobecker To: Jan Kratochvil Cc: Doug Evans , gdb-patches@sourceware.org, David Malcolm , Tom Tromey Subject: Re: [RFA] ignore PYTHONHOME environment variable. Message-ID: <20101214103305.GU2596@adacore.com> References: <1290474202-885-1-git-send-email-brobecker@adacore.com> <20101123030037.GA19962@host0.dyn.jankratochvil.net> <20101123163045.GA1737@host0.dyn.jankratochvil.net> <20101123173054.GW2634@adacore.com> <20101214071210.GQ2596@adacore.com> <20101214092645.GA20415@host0.dyn.jankratochvil.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101214092645.GA20415@host0.dyn.jankratochvil.net> User-Agent: Mutt/1.5.20 (2009-06-14) Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2010-12/txt/msg00225.txt.bz2 > 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