[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: decision on moving core packages to ELPA; also move to obsolete?
From: |
Eli Zaretskii |
Subject: |
Re: decision on moving core packages to ELPA; also move to obsolete? |
Date: |
Wed, 16 Dec 2020 19:56:52 +0200 |
> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: stephen_leake@stephe-leake.org, daniele@grinta.net, emacs-devel@gnu.org
> Date: Tue, 15 Dec 2020 17:09:11 -0500
>
> What I'm suggesting is the following:
>
> - the tarball we build will include the same file as before in
> `emacs/lisp`.
> - it will additionally contain a new directory `emacs/elpa` in which
> each bundled package has its own directory (all in the normal format
> of installed packages in ~/.emacs.d/elpa).
So we will have 2 copies of each package's Lisp files in the tarball?
> So until `package-activate-all` is called, the bundled packages will
> just sit there on your file system but Emacs won't "see" them.
This already happens, right? we already call package-activate-all at
startup, right?
> We could also place some or all of the bundled packages directly inside
> `lisp`
Now I'm confused: how 'lisp/' is different from 'emacs/lisp' you
mentioned above?
> and have them be activated in the same way all other Emacs's code
> is activated (i.e. basically by loading `loaddef.el` at dump time), so
> they'll behave a bit less like normal packages and a bit more like Org
> and Tramp do now (i.e. you can't "not have them"), but I think the above
> suggestion is more conservative and flexible for the user (the downside
> is that it's less efficient at startup).
What are the pros and cons of each of these 2 alternatives? I think
we should carefully consider them before deciding which one we prefer.
- Re: decision on moving core packages to ELPA; also move to obsolete?, (continued)
- Re: decision on moving core packages to ELPA; also move to obsolete?, Stefan Monnier, 2020/12/15
- Re: decision on moving core packages to ELPA; also move to obsolete?, Eli Zaretskii, 2020/12/15
- Re: decision on moving core packages to ELPA; also move to obsolete?, Stefan Monnier, 2020/12/15
- Re: decision on moving core packages to ELPA; also move to obsolete?, Michael Albinus, 2020/12/16
- Re: decision on moving core packages to ELPA; also move to obsolete?, Stefan Monnier, 2020/12/16
- Re: decision on moving core packages to ELPA; also move to obsolete?, Michael Albinus, 2020/12/16
- Re: decision on moving core packages to ELPA; also move to obsolete?, Andrea Corallo, 2020/12/16
- Re: decision on moving core packages to ELPA; also move to obsolete?,
Eli Zaretskii <=
- Re: decision on moving core packages to ELPA; also move to obsolete?, Stefan Monnier, 2020/12/16
- Re: decision on moving core packages to ELPA; also move to obsolete?, Eli Zaretskii, 2020/12/16
- Re: decision on moving core packages to ELPA; also move to obsolete?, Stefan Monnier, 2020/12/16
- Re: decision on moving core packages to ELPA; also move to obsolete?, Eli Zaretskii, 2020/12/15
- Re: decision on moving core packages to ELPA; also move to obsolete?, Stefan Monnier, 2020/12/15
- Re: decision on moving core packages to ELPA; also move to obsolete?, Eli Zaretskii, 2020/12/15
- Re: decision on moving core packages to ELPA; also move to obsolete?, Stefan Monnier, 2020/12/15
- Re: decision on moving core packages to ELPA; also move to obsolete?, Eli Zaretskii, 2020/12/16
- Re: decision on moving core packages to ELPA; also move to obsolete?, Stefan Monnier, 2020/12/16
- Re: decision on moving core packages to ELPA; also move to obsolete?, Eli Zaretskii, 2020/12/16