From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: Re: BBDB v3 approaching release Date: Fri, 31 May 2013 02:25:46 +0900 Message-ID: <877gigcrc5.fsf@uwakimon.sk.tsukuba.ac.jp> 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> <20902.64600.858912.770771@gargle.gargle.HOWL> <878v2wdhaz.fsf@uwakimon.sk.tsukuba.ac.jp> <20903.13593.858294.636072@gargle.gargle.HOWL> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Trace: ger.gmane.org 1369934769 26454 80.91.229.3 (30 May 2013 17:26:09 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 30 May 2013 17:26:09 +0000 (UTC) Cc: emacs-devel@gnu.org To: "Roland Winkler" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu May 30 19:26:09 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 1Ui6c4-00039M-A7 for ged-emacs-devel@m.gmane.org; Thu, 30 May 2013 19:26:08 +0200 Original-Received: from localhost ([::1]:46356 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ui6c3-0007iH-Sr for ged-emacs-devel@m.gmane.org; Thu, 30 May 2013 13:26:07 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:41704) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ui6bt-0007hv-4I for emacs-devel@gnu.org; Thu, 30 May 2013 13:26:02 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ui6bn-0006WV-Qd for emacs-devel@gnu.org; Thu, 30 May 2013 13:25:56 -0400 Original-Received: from mgmt2.sk.tsukuba.ac.jp ([130.158.97.224]:60865) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ui6bn-0006V1-62; Thu, 30 May 2013 13:25:51 -0400 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt2.sk.tsukuba.ac.jp (Postfix) with ESMTP id 7373D970922; Fri, 31 May 2013 02:25:47 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 005C31A298C; Fri, 31 May 2013 02:25:46 +0900 (JST) In-Reply-To: <20903.13593.858294.636072@gargle.gargle.HOWL> X-Mailer: VM undefined under 21.5 (beta32) "habanero" b0d40183ac79 XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 130.158.97.224 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:159933 Archived-At: Roland Winkler writes: > On Thu May 30 2013 Stephen J. Turnbull wrote: > > TeX is happy to pick up such files from the current directory. Why > > would it be a problem? If that doesn't work or the BBDB includes are > > shadowed, TEXINPUTS=.:$TEXINPUTS should do the trick. man kpathsea > > for more information about telling TeX where to find stuff. > > Normally the user directory where bbdb-print creates its TeX file is > not (should not be!) the directory where BBDB keeps its TeX include > files. That's one good way to do it, but not necessarily normal. An installed ELPA package can (and IMO should) be thought of as a binary whose internal structure happens to take advantage of the file system to organize its parts rather than ELF sections or zipfile members. In this it's similar to a Python package or a Mac OS X .app. People who want to fiddle with the internals of a package really should do so in the *source* tree, not in the installed tree. The installed tree will have a more convenient layout for source browsing. I'll grant that the info files are a special case and a PITA because they really do like to live in one directory. Nevertheless that can be dealt with in a number of ways (I think XEmacs implements three, none of them particularly attractive). Ulrich mentioned FHS. Well, I haven't read the FHS carefully in a decade, but IIRC from back then, the FHS does not in any way rule out such "opaque packages". If you want your package resources to be available via system facilities (and for man pages and info files you certainly do, thus the exception just mentioned), then indeed you want to follow FHS. But internal resources (including build-time-only resources) can go anywhere you want. There are disadvantages to "opaque packages". It can take a lot more stats to find stuff if you have a very flexible path search algorithm such as kpathsea, which slows things quite a bit. On those occasions you do want to break the veil, what you see inside the package may be neither pretty nor convenient. But by the same token they tend to increase cohesion and decrease coupling, which are usually considered design goals. You don't have to like this approach; I'm just saying it's one way to look at ELPA packages that helps to rationalize them and emphasize their benefits.