From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: BBDB v3 approaching release Date: Thu, 30 May 2013 10:37:56 -0400 Message-ID: References: <20899.5836.285028.24953@gargle.gargle.HOWL> <87obbvwgw6.fsf@sbs.ch> <20901.8264.9162.330645@gargle.gargle.HOWL> <20902.12476.291747.710823@a1i15.kph.uni-mainz.de> <20903.7625.861080.943448@a1i15.kph.uni-mainz.de> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1369924693 3308 80.91.229.3 (30 May 2013 14:38:13 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 30 May 2013 14:38:13 +0000 (UTC) Cc: Christian Egli , Roland Winkler , emacs-devel@gnu.org To: Ulrich Mueller Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu May 30 16:38:12 2013 Return-path: Envelope-to: ged-emacs-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 1Ui3zX-0004W2-CC for ged-emacs-devel@m.gmane.org; Thu, 30 May 2013 16:38:11 +0200 Original-Received: from localhost ([::1]:59905 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ui3zX-0004r4-1X for ged-emacs-devel@m.gmane.org; Thu, 30 May 2013 10:38:11 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:52365) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ui3zQ-0004qv-3l for emacs-devel@gnu.org; Thu, 30 May 2013 10:38:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ui3zL-0000GG-3j for emacs-devel@gnu.org; Thu, 30 May 2013 10:38:04 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.182]:5144) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ui3zK-0000GB-VC; Thu, 30 May 2013 10:37:59 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EABK/CFFFpYtM/2dsb2JhbABEvw4Xc4IeAQEEAVYjBQsLDiYSFBgNJIgeBsEtkQoDklqSIIFegxM X-IPAS-Result: Av4EABK/CFFFpYtM/2dsb2JhbABEvw4Xc4IeAQEEAVYjBQsLDiYSFBgNJIgeBsEtkQoDklqSIIFegxM X-IronPort-AV: E=Sophos;i="4.84,565,1355115600"; d="scan'208";a="15191479" Original-Received: from 69-165-139-76.dsl.teksavvy.com (HELO pastel.home) ([69.165.139.76]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 30 May 2013 10:37:52 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 18A126A668; Thu, 30 May 2013 10:37:56 -0400 (EDT) In-Reply-To: <20903.7625.861080.943448@a1i15.kph.uni-mainz.de> (Ulrich Mueller's message of "Thu, 30 May 2013 11:37:13 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.182 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:159925 Archived-At: >>> How do I configure install locations of a package if it's in ELPA >>> format? >> You don't. > Why is this better than having them configurable? Because that saves you from having to configure it. > Especially, why are you asking that a package like BBDB that has > a perfectly working autoconf build system should _remove_ it? I didn't ask to remove it: it can be kept in the ELPA package. It's just not useful/needed for the usual ELPA style of distribution/installation. >>> Especially, if the package has non-lisp components? >> You leave them alongside the Elisp files. > Emacs itself uses a different layout and keeps non-lisp files in > different directories like etc or info. Indeed. In some cases it was a good choice, in others I'm not so sure. > (Hopefully there are no plans to change that?) It's definitely not important enough to waste time changing it unless there's a good reason for it. > For example, for Info files it's really a PITA if they're not > collected in one (or at least, few) central locations. Why? >> And when you need them, your Elisp package will find them by looking >> around itself (it can get access to its own location via >> `load-file-name'). > This means that anyone who wants to adhere to some standard like FHS > must move files around manually. I had to do this way too often when > packaging things for Gentoo. I don't see any particular reason why you'd feel compelled to break an ELPA package into its constituents and spread them around in different directories, just for the sake of following some standard. If there's a real benefit to it and it's higher than the cost of moving things around, then by all means go for it. But "the ELPA way" is pretty damn convenient and I personally can't think of any benefit you'd get from applying the FHS to it. > Most packages are at least friendly enough and spend a defvar or > defcustom that allows to configure these directories (often with a > fallback to the above-mentioned load-file-name location). In order to be able to use load-file-name, you need to evaluate it during load and save it in some global variable. So, yes, a natural way to do it ends up introducing defvar/defcustoms for that anyway. Stefan