GNU ELPA is the official GNU Emacs package repository. It's the only one enabled by default, which means that it has the greatest reach. At the same time, submitting a package there is a bit of a hassle and requires an FSF copyright assignment, which means it has a relatively limited selection of packages.
MELPA and Marmalade are both third-party package ...
First of all, ELPA is the name of a specification, the Emacs Lisp Package Archive. There are three widely known implementations of that specification, GNU ELPA, Marmalade and MELPA.
GNU ELPA is the official GNU Emacs archive, enabled out of the box for sufficiently new Emacs installations. It is comparatively small, contributing to it requires copyright ...
The way I think of it, some repos have more overhead involved with submitting packages than others; the repos with more overhead tend to have fewer packages. In order from most to least overhead:
GNU ELPA requires all code to be GPL'd and copyright assigned to the FSF. ELPA code is essentially "owned" by the core Emacs team, so there's much less of it than ...
set package-check-signature to nil, e.g. M-: (setq package-check-signature nil) RET
download the package gnu-elpa-keyring-update and run the function with the same name, e.g. M-x package-install RET gnu-elpa-keyring-update RET.
reset package-check-signature to the default value allow-unsigned
This worked for me.
As stated in the package the following holds:
There are several package repositories available.
GNU ELPA is the official package repo.
It's small, and requires copyright assignment (of all authors of a package) to the FSF to contribute to it.
Packages on GNU ELPA are really just a git repo. The advantage of being hosted here is that the core team try to update packages if Emacs itself adds ...
The problem you're referring to is probably that when you upgrade a package from within an Emacs session where that package is already in use, the old version of the package will sometimes interfere during compilation of the new version, leading to miscompiled files.
There is a tentative fix for that in Emacs-25, but AFAIK the problem is still present in 24....
I set up a local package archive (Emacs 24.5) using package.el by first creating two directories, pkgs and local. (The names don't matter.) The files comprising your packages go in pkgs, and local will end up holding your archive. If you want to make an archive available to others, you can expose local using a web server, but the process is the same as ...
FWIW - I had this issue with the signature org-20140407.tar.sig. Like Sigma's package-check-signature is/was allow-unsigned.
I changed the package-check-signature value to nil and the problem was resolved.
If you try to install the package gnu-elpa-keyring-update (which seems to have the purpose of updating the keys used by the package manager), you will see in its description that you can do:
gpg --homedir ~/.emacs.d/elpa/gnupg --receive-keys 066DAFCB81E42C40
on the commandline to get new keys manually. To make sure you are asking for the correct key (...
Some additional info, to supplement the other answers here.
Some info about MELPA and MELPA "stable" -
Start by looking at this pretty-much duplicate question, from StackOverflow, including the comments for the question itself. In particular, this comment that I posted, after exchanging email with Donald Curtis (maintainer of MELPA and MELPA stable):
When you update your packages through the M-x list-packages interface, after the successful installation of the package, you'll get asked if you want to remove the old package. Don't delete them so they stay in place and you could then later remove the newer package through this interface.
My current package list shows 4 versions of magit installed in my ~/....
You want to change the variable package-user-dir:
(setq package-user-dir "~/.emacs.d/packages")
Change this setting before calling (package-initialize) or anything involving loading or installing packages, but after (require 'package).
How I found this:
I use Helm, which makes it easy to search through Emacs's functions and variables. I called describe-...
The "nuclear option", as it were, would be to ditch package.el entirely and instead use the package manager that I wrote, straight.el. The advantage would be that straight.el installs packages by cloning their Git repositories, thereby making it trivial to use whichever version you would like. Also, straight.el provides functionality for dealing with ...
It is true that MELPA no longer pulls libraries from EmacsWiki.
Please obtain Dired+ and other libraries by me from EmacsWiki: dired+.el.
All of my pages on EmacsWiki are locked (they require a site administrator to unlock them). There has never been an actual security problem reported, AFAIK.
Yes, it is true that a locked web page does not present the ...
Well you've answered your own question: package.el is the standard way to install packages, because it's built into Emacs 24.
Everything else is non-standard (and probably somewhat subjective. I manage most third-party libraries via el-get, personally).
The basic way to use packages^(1) is pretty simple:
Add to your init file:
(require 'package) ;; You might already have this line
'("melpa" . "https://melpa.org/packages/"))
(when (< emacs-major-version 24)
;; For important compatibility libraries like cl-lib
There are several:
Quelpa allows for fetching packages from arbitrary sources and building them into a format that can be installed by package.el
Install Emacs packages listed on MELPA, GNU ELPA, or Emacsmirror, or provide your own recipes. Packages are cloned as Git (or other) repositories.
Assimilate Emacs packages as Git submodules.
I have written a new package manager for Emacs, straight.el, which attempts to improve on all existing package management solutions. There is an extensive section in the straight.el documentation about comparisons to other package managers, but here is a very short summary:
package.el downloads opaque tarballs from central servers, with no option for ...
Melpa's source is available, so you could just clone and run that on a server configured to be accessible from only inside your office (and not the whole internet). Your developers would have to be able to access the server, and would have to add the archive to package-archives the same way one does Melpa, Marmalade, or others. The packages would show up in ...
As pointed out by Nsukami, package.el does support system-wide packages. But as your subsequent question points out, it does not provide any special help to install packages in a system-wide manner.
One way you can do that is by using something like:
(setq package-user-dir "/usr/share/emacs/site-lisp/elpa")
in your root account's ~/.emacs. This will ...
'(("melpa" . "https://melpa.org/packages/")
("gnu" . "https://elpa.gnu.org/packages/")
("org" . "http://orgmode.org/elpa/")))
to your emacs init file. Adding the org repo will put the latest version of org-mode in list-packages, where you can update it just like any ...
The server configuration on marmalade.org is broken: It does not serve the intermediate certificate it is using. This has been pointed out in half a dozen of issues now at https://github.com/nicferrier/elmarmalade -- I can discern no action.
So one can say that marmalade is defunct.
Unfortunately, I also don't know yet how to make the Emacs package ...
The correct solution (IMO) is to use a package manager which has explicit support for this use case. This would be straight.el, which I wrote for this purpose.
You can read verbose documentation, including comparisons to other package managers, in the README, so I'll stick to how you can use straight.el to solve your specific problem.
Place your repository ...
Is this normal?
Yes, MELPA recently updated its policy and no longer includes packages hosted on EmacsWiki, quoting security reasons: https://github.com/melpa/melpa/pull/5008. See also Drew's answer.
For now you will have to install it either from its upstream EmacsWiki source at https://www.emacswiki.org/emacs/dired%2b.el or from its (potentially outdated)...