Re: BBDB v3 approaching release

["Stephen J. Turnbull" <stephen@xemacs.org>]

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.