Re: Bundling GNU ELPA packages

[Eli Zaretskii <eliz@gnu.org>]

> From: Tassilo Horn <tsdh@gnu.org>
> Date: Thu, 06 Nov 2014 20:30:08 +0100
> Cc: emacs-devel@gnu.org
> 
> What I don't understand is why we don't move org, gnus, and other
> built-in packages which aren't "super-core" (i.e., not everybody
> needs them) from emacs.git to elpa.git?  Then all points above still
> apply, and emacs releases are a bit more lightweight.

There's no direct relation between moving packages between
repositories and excluding them from the release tarballs.  We can
have one, but not the other.

What is the advantage of having a more lightweight tarball?  Disk
space is no longer at premium, and Emacs is a relatively small package
by modern standards.

> I mean, for fast-evolving packages like org and company, if emacs
> 25.1 bundles version X, the next day version X+1 is available from
> ELPA anyway.

Yes, but then installing a tarball gives me Org and Gnus etc., even if
they are slightly outdated.  If we go your way, I don't have them at
all, and need a live, reliable, and uncensored network connection to
get them; until I do, my Emacs is crippled or might not even start at
all.  That's a net loss.

When I install XEmacs, I always want the "sumo" package, for that very
reason.

> The only downside I can see is that users upgrading from Emacs 24 to 25
> might get startup errors because formerly built-in packages aren't
> anymore.  But that can be documented easily:
> 
>   If you used the built-in org-mode version in Emacs < 25, do
> 
>     1. emacs -Q
>     2. M-x package-install RET org RET
>     3. Now you can restart emacs without -Q

There are only disadvantages here.  You add conditions that, if they
are not satisfied, will interfere with the upgrade.  It's a nuisance
for no good reason.