emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: BBDB v3 approaching release


From: Stefan Monnier
Subject: Re: BBDB v3 approaching release
Date: Thu, 30 May 2013 10:37:56 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux)

>>> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]