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

[Phillip Lord]

John Wiegley <address@hidden> writes:

>>>>>> "AS" == Alain Schneble <address@hidden> writes:
>
> AS> /usr/local/share/info/org.info.gz
> AS> /usr/local/share/emacs/26.0.50/etc/ORG-NEWS
> AS> /usr/local/share/emacs/26.0.50/etc/org/README
> AS> /usr/local/share/emacs/26.0.50/etc/org/.*\.xml
> AS> /usr/local/share/emacs/26.0.50/etc/refcards/orgcard.tex
> AS> /usr/local/share/emacs/26.0.50/lisp/org/.*\.(el\.gz|elc)
>
> AS> Unless I'm misundarstanding you, using your approach, all files will end
> AS> up in /usr/local/share/emacs/26.0.50/lisp/org (using the example
> AS> configuration I gave above).
>
> AS> Do you really want to give up this standard file structure?
>
> I think we should *not* give up the standard file structure. At least not now.
> Using ELPA should feel "first class" for those authors contributing packages
> that are to become part of the standard distribution.
>
> Perhaps in future, for the sake of ease-of-upgrading, we'd want to change this
> policy, but one thing at a time.

It's worth considering what ease-of-upgrading means. At the moment, for
example, if I install org-mode with ELPA package.el generates all the
autoloads for org-mode and sticks them into a file. All is good.

But the old autoloads are still there, stuck in loaddefs.el in non-user
space, non-removable or changable. Functions that are in the
/usr/share/emacs installation but NOT in the ~/.emacs.d/elpa
installation will remain autoloaded, even though they should not be.

If org mode were it's own directory, with it's own org-autoloads.el,
then package.el could (and already does I believe) just not autoload any
of the functions from the old version of org-mode, nor put any of its
files into load-path.

It seems to me that one of the major use cases for adding core/tarball
ELPA support is enable packages to be present by default in an Emacs
tarball download, while still allowing upgrading from ELPA (or the
org-mode repo).

I cannot see how to address this using the "copy files from ELPA into
core" build, at least not with significant replumbing of the current
emacs build; perhaps someone else can, but it is worth considering this
when thinking about the valid but generic concerns I am hearing about
change.

Phil