From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Mark H Weaver Newsgroups: gmane.lisp.guile.devel Subject: Re: Guile's DATAROOTDIR and DATADIR Date: Fri, 15 Jul 2016 13:25:46 -0400 Message-ID: <87shvavmn9.fsf@netris.org> References: <83furb6zs7.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1468603583 29513 80.91.229.3 (15 Jul 2016 17:26:23 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 15 Jul 2016 17:26:23 +0000 (UTC) Cc: guile-devel@gnu.org To: Eli Zaretskii Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Fri Jul 15 19:26:12 2016 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1bO6sN-0004gB-J9 for guile-devel@m.gmane.org; Fri, 15 Jul 2016 19:26:11 +0200 Original-Received: from localhost ([::1]:34002 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bO6sM-0000Of-U4 for guile-devel@m.gmane.org; Fri, 15 Jul 2016 13:26:10 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42291) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bO6sE-0000Mg-T7 for guile-devel@gnu.org; Fri, 15 Jul 2016 13:26:04 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bO6sB-0000Ib-M4 for guile-devel@gnu.org; Fri, 15 Jul 2016 13:26:02 -0400 Original-Received: from world.peace.net ([50.252.239.5]:54221) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bO6sB-0000I5-I4; Fri, 15 Jul 2016 13:25:59 -0400 Original-Received: from pool-71-174-37-60.bstnma.east.verizon.net ([71.174.37.60] helo=jojen) by world.peace.net with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1bO6rb-0004xg-2a; Fri, 15 Jul 2016 13:25:23 -0400 In-Reply-To: <83furb6zs7.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 15 Jul 2016 12:01:12 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.95 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 50.252.239.5 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Original-Sender: "guile-devel" Xref: news.gmane.org gmane.lisp.guile.devel:18504 Archived-At: Eli Zaretskii writes: > "./configure --help" says: > > Fine tuning of the installation directories: > [...] > --datarootdir=DIR read-only arch.-independent data root [PREFIX/share] > --datadir=DIR read-only architecture-independent data [DATAROOTDIR] > > AFAIU, this means PREFIX/share/guile/2.0/ is where the *.scm files > will be installed. That is, installing Guile 2.0.12 will overwrite > the Scheme files that were installed there by previous Guile 2.0.x > versions. > > If the above is true, then the question that bothers me is whether > replacing these files might cause any trouble for programs that were > compiled against previous Guile 2.0.x versions (like GDB and Make, for > example). If there are potential incompatibilities visible on the > Scheme level, then I think a versioned directory under > PREFIX/share/guile/2.0/ would be in order, so that several versions of > Guile could live on the same system. > > The same issue arises with the cache directory, where the *.go files > are installed (I have those in LIBDIR/guile/2.0/ccache/). We are aware of these potential issues, which is why we must be careful to ensure ABI compatibility within a stable release series, e.g. within 2.0.x. If we accidentally break something that uses Guile within a stable series, that's a bug. In practice, we seem to be doing a good job of ensuring ABI compatibility within 2.0.x, based on the lack of bug reports of this nature. I don't recall seeing reports of upgrades within 2.0.x causing breakage, outside of simple bugs. Having said this, I will admit that we've not maintained perfect ABI compatibility within 2.0.x, e.g. we've removed some obscure interfaces that were intended to be kept private, or were broken and could not be easily fixed, and that we believed to be unused in practice. This is not ideal, and I think we will need to be much more strict about this in the future, as Guile becomes more widely used. In any case, to the extent that there's a problem here, the solution is to redouble our efforts to avoid ABI breakage. The solution is most definitely *not* to have separate directories for every maintenance release. The reason is that we want existing Guile programs compiled against 2.0.11 to benefit from the bug fixes in 2.0.12. Does that make sense? Mark