Re: feature/integrated-elpa 4f6df43 15/23: README added

[Eli Zaretskii]

> From: Andy Moreton <address@hidden>
> Date: Fri, 14 Oct 2016 14:51:15 +0100
> 
> >> ~/.emacs.d/elpa/org/org
> >> ~/.emacs.d/elpa/org/etc/ORG-NEWS
> >> ~/.emacs.d/elpa/org/org.el
> >> 
> >> So, org-mode has to support two independent directory layouts.
> >
> > But Org already supports those two formats.  We don't require Org to
> > do anything that it doesn't already do.  So staying with the current
> > structure of lisp/ in the Emacs tree doesn't add any new requirements.
> 
> But that would do nothing to reduce the unnecessary and duplicated
> packaging work.

I'm not sure I understand what duplicated work you have in mind.  Org
developers will still put Org on ELPA in the same directory structure
they do now.  When Org is imported into Emacs, as part of building a
release tarball or as part of building from the repository, each file
will be put in its natural place in the Emacs source tree, either by
package.el or by some other means, and will replace any previous Org
files, if there were such.

When end-users want to upgrade to a version of Org newer than what
they have bundled in the latest Emacs release, the Org files will be
placed under ~/.emacs.d/elpa/org/, as they are now.

> Keeping each package in ELPA format ensures that replacing the package
> can be done easily, as everything is isolated in a single directory.

I see no particular difficulties in putting several files into several
directories, software can and does do that all the time.  It's not
like we will be asking users to do this manually.

> If the package is shipped in the emacs tarball and the user then
> upgrades to a newer version from ELPA, only the load path needs to
> change.

This part doesn't need to change at all, under my proposal.

> In additon, the user can easily compare the changes bewteen the package
> version shipped in the emacs tarball and the updated one fetched from
> ELPA, as the package layout is the same.

What for?  There should be NEWS in the new Org release.  Those more
details regarding the changes can always look in the Org Git repo.

> There are many more users of emacs than developers, so the design
> should be aimed at utility and convenience for users.

That's the main motivation for my proposal, indeed.