Future role of ELPA (was: [ELPA] tramp-theme.el)

[Stefan Reichör]

John Wiegley <address@hidden> writes:

>>>>>> Stefan Reichör <address@hidden> writes:
>
>> As a user I really don't like that a lot of functionality is now moved to
>> ELPA. When I install a new emacs, I have to re-install also all needed
>> packages from ELPA.
>>
>> It would be so much easier when all the batteries in emacs are still
>> included.
>
> The future plan is to move even more things into ELPA. However, parts of ELPA
> will be included in future Emacs tarballs, so your batteries will actually be
> there in that future.
>
> So, rather than asking whether things can move back into Emacs, the better
> question is: how should we proceed with our plan to deeply integrate ELPA, so
> questions like this are resolved in passing. We've had some progress in this
> direction, but there are still a few matters of process to resolve.

I am reading the emacs devel list. And I know that this is the direction
that is desired by most/all developers.

As I user I am not happy with that direction.
Let me try to explain it.
I use Emacs since about 20 years. I use it daily and it is my primary
interface to computer related tasks. For sure I can adopt to what ever
direction emacs goes.

I use a hand crafted .emacs and I am used to install emacs packes
manually to a site-lisp folders.

Consider a simple customization like tramp-theme. When everything is in
stock emacs: I just can change the value of a customization variable and
see what happens.

With GNU ELPA I have to install the package first and get rid of it if I
don't like it.

My main concern with GNU ELPA is that I have to install a lot of extra
packages manually using the package manager. When they are built-in they
are just there.

So I hope that many useful features will still be shipped with Emacs as
integrated packages.

Stefan.