Re: [Emacs-diffs] feature/integrated-elpa 4f6df43 15/23: README added

[Phillip Lord]

Alain Schneble <address@hidden> writes:

> address@hidden (Phillip Lord) writes:
>
>>> Do you really want to give up this standard file structure?
>>
>> Yes, because it is not standard. It's one of two standards.
>>
> If she chooses to use it and install *additional* packages, then I
> think it is legitimate to keep and use this ~/.emacs.d/elpa/
> structure.

Or upgrades existing ones.



>> So, org-mode has to support two independent directory layouts. If we use
>> package.el as part of the core or tarball emacs build, then org-mode has
>> to support only one directory layout.
>
> Maybe I'm naive, but I don't see an issue in supporting both layouts.

Two layouts have to be supported. It's just a question of who has to
support them. In my scheme, it's core emacs, in your scheme its
individual package developers.

Probably in most cases, it's not a big deal, and it will happen
automatically.

>> The Emacs build will, for the foreseeable future, have to support two
>> layouts, that is true. But, Emacs already does and it is (or rather was)
>> relatively easy to add to the build.
>
> Maybe or maybe not.  If we would use the current structure for ELPA core
> and ELPA tarball packages, then the build wouldn't have to support the
> /lisp/packages/[package] structure that follows the
> ~/.emacs.d/elpa/[package] layout.  It would only have to know how to
> copy the package files to the proper locations.


I think the semantics of understanding how to copy the package files to
the legacy (er, proper) locations is pretty much the same as package.el
already has just for loading them.

Oh, and, all of this copying has to happen *before* we generate
loaddefs.el which means it has be done with bootstrap-emacs, which is a
tricky bit of the build to be fiddling with.

Phil