I notice that there are several different repositories that often contain the same software. Why would I want to prefer:

  • Marmalade

over the others? Since any one repository does not contain all the packages that I want, is it a good idea to have these repositories enabled simultaneously?

  • This discussion can now (2022) include NonGNU ELPA. Primarily it requires package's license to be compatible to GPLv3 and does not require copyright assignments.
    – prash
    Commented Jun 24, 2022 at 19:37

4 Answers 4


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 repositories. They're not officially supported by GNU, but also have much larger selections of packages. Package quality is a bit more variable, but you're much more likely to find whatever you're looking for, especially if it's a bit obscure.

Marmalade and MELPA have slightly different models for package uploaders. My understanding is that MELPA tracks a version control repository directly (ie via GitHub), letting package authors update packages just by pushing commits to a branch. Marmalade, on the other hand, has people upload packages to the repository explicitly.

In practice, I haven't seen much difference between MELPA and Marmalade. There isn't much downside to enabling both of them to have the largest possible selection of installable packages: I've been using both (and GNU ELPA, of course) for a while with no significant problems.

One possible concern (which I haven't run into myself) with having both repositories enabled, which I haven't run into myself, is having packages available from both at different versions. By default, the package manager (package.el) does not have any way to resolve conflict like this; however, you can resolve this by installing the melpa package which lets you customize which packages are provided or excluded from which repositories. You can see more details here or from the documentation for the melpa package.

As @Malabarba helpfully pointed out, this problem is resolved in Emacs 24.4.

If you're really worried about security, you may want to avoid both MELPA and Marmalade because they let anyone upload packages and, as far as I know, don't have any proactive security arrangements. The GNU ELPA repository, on the other hand, is managed by the FSF and has signed packages which should help. Of course, if security is really important, you might want to just review and install elisp packages by hand instead of using the package manager.

  • 14
    The new package.el that comes in emacs 24.4 handles diverging version numbers gracefully. If two repos have the same package with different version, you're offered both, and one will never override the other during an update.
    – Malabarba
    Commented Sep 25, 2014 at 19:16
  • 1
    @Malabarba: Wow, that's great to hear! Commented Sep 25, 2014 at 19:44
  • 14
    This is a good answer but should probably also mention MELPA stable (melpa-stable.milkbox.net). MELPA will automatically get the latest revision from a repo's master branch, while MELPA stable will get the latest tagged revision.
    – shosti
    Commented Sep 25, 2014 at 20:43
  • @shosti: Oh neat, I didn't know about that. It might be good to put that as its own answer, actually. Commented Sep 25, 2014 at 20:44
  • 7
    marmalade doesn't allow anyone to upload packages. only registered users. I know all the uploaders right now. So there is some sort of peer review. Commented Oct 18, 2014 at 19:11

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:

  1. 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 with other repos. (org-mode has its own repo, but it has the same mode of operation.)
  2. Marmalade requires all code to have a GPL-compatible license and all packages are manually uploaded. Ownership is a little unspecified, and changing ownership doesn't have a set process AFAIK.
  3. MELPA Stable is more or less in direct competition with Marmalade, except it has no license restrictions and automatically builds packages from git repos using the latest tagged revision. Ownership is determined through the MELPA repo (ownership changes occur through pull request).
  4. MELPA is like MELPA stable except it always pulls from the latest revision on the master branch of a git repo. The packages tend to be "bleeding-edge", and it can be a bit of a free-for-all stability-wise (which has pros and cons).

Personally I think either MELPA Stable or Marmalade will probably win out in the long run for most users—MELPA proper is pretty unstable and ELPA is too restrictive to be really scalable for lots of packages. But that's just an opinion.

  • 6
    marmalade does now have API for adding owners to packages. Commented Oct 18, 2014 at 19:12

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 or deprecates features.

Built from source

MELPA is the biggest and fastest growing package repo. It releases a new version every time a new version is pushed to a repo, or an EmacsWiki page is updated.

It's bleeding edge, but it works very well in practice. MELPA is curated to avoid duplicate packages, and to ensure that the canonical home of package is recorded (instead of a random fork).

MELPA does have the problem that versions are just timestamps, e.g. my-package-20131231.2359. This means if you depend on my-package:

;; Package-Requires: ((my-package "1.2.3"))

then Emacs will think that any version on MELPA is new enough.

MELPA Stable is the same as MELPA, but rather than using datestamp versions, it uses the versions in git tags. This allows for better dependency resolution, but has issues with depending on wiki packages.

User uploads

Marmalade is much more like a traditional repository from other programming languages. The package developer uploads the package to Marmalade when they do a release.

In principle, this gives packages a proper release process (Marmalade predates MELPA stable) and also avoid the autogenerated version number problem. However, there's no identity verification. Anyone can upload a package, even if they didn't write it. This gets difficult if the maintainer of my-package finds that someone else uploaded my-package and can't subsequently upload new versions.

Marmalade used to be a node.js app, and it's now written in elisp. Both versions have had uptime problems occasionally.


Org-mode ELPA is a repo that only hosts org and org-plus-contrib. Org-mode is part of Emacs core, but it's developed externally and the code is only synced with Emacs trunk periodically. This repo lets you have the bleeding-edge org-mode.

User42 ELPA is a repo for a single package developer who has released quite a range of Emacs packages. If you like any of his packages, you could add this repo.

Sunrise Commander ELPA is a repo for extensions for Sunrise Commander (an Emacs package for file browsing, inspired by midnight commander).


Tromey's ELPA was the first repo set up. It is officially replaced with GNU ELPA, but it didn't have the same copyright assignment requirements. As of 2010, it is no longer updated.

Elpy package archive contained various packages developed by Jorgen Schaefer for 'Elpy, the Emacs Python Development Environment', but that has migrated to MELPA Stable.

  • 4
    marmalade definitely has had uptime problems... I believe I've solved them with nic.ferrier.me.uk/blog/2014_08/deploying-blue-green-with-docker -- no one has mentioned the risks involved in using github, a commercial provider of web based software, as a backend; I believe that is a risk. Marmalade is free software and even the built thing is installable by someone else. Commented Oct 18, 2014 at 19:21
  • no one has mentioned the risks involved in using github, a commercial provider of web based software, as a backend: but I'm sure those concerns will disappear now that it's Microsoft GitHub ;-)
    – TomRoche
    Commented Jun 14, 2018 at 4:07

Some additional info, to supplement the other answers here.

  1. 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):

    From his point of view [Donald Curtis's, and as I understand his communication to me], the "stable" MELPA site is in maintenance mode only. And the only reason that code like mine is not there is that no one has implemented uploading from the wiki [Emacs Wiki] for the "stable" site. Also, there is no "curating" done by anyone - no filtering to determine whether a package is stable, risky etc. The existence of two sites was requested by some package developers who wanted to distinguish dev versions of their packages from older ("stable") versions.

    In sum, there is nothing that is inherently more "stable" about the content on "MELPA stable". The version numbering and feed method can be different; that's all. And if a particular package maintainer wants to distinguish "stable" from "development" versions, and wants to do that by uploading them to the two different sites, then that is the effect - for that package.

  2. One difference between MELPA and Marmalade (and GNU ELPA) is that it is not required that code contributed to MELPA be sourced from a git repository. In particular, it can be automatically pulled from the Elisp Area of Emacs Wiki.

    Does that mean, as some have said, that anyone can upload anything, and you have no way of knowing whether the code is actually by the claimed author, etc.? Yes and no. In general, yes: anyone is free to upload Elisp code to Emacs Wiki. As the top of the Elisp-Area page says:

    This is the EmacsWiki elisp area, where we collect EmacsLisp files. No login required, no version control required, no ftp required, no password required. It’s as simple as the wiki itself. That also means that anybody can place malicious code in these EmacsLisp files. If in doubt, don’t use them.

    However, just so you know, I am an administrator of the wiki, and my own Lisp libraries in the wiki Elisp Area are locked pages. That means that only a wiki administrator can upload them. So in this case, you can be pretty sure that libraries of mine that you download from MELPA or Emacs Wiki were uploaded by me. As with everything on the Internet, however, there is no ironclad guarantee, just as there is no guarantee with the code itself. As the GPL blurb in every GPL library says:

    This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

HTH. Happy hacking.

  • very reassuring I'm sure. Commented Nov 17, 2014 at 22:57
  • 2
    Let me disagree with your MELPA opinion. Package author does not „release” anything to MELPA. He or she just commits to his own repo, and MELPA picks it up. The difference is that MELPA picks anything, while MELPA stable picks tagged releases. This is in fact a matter of preference. Some people prefer to always make feature branch, treat trunk as sacred, and signal that change is ready by merging to trunk. Others happen to develop on trunk but mark ready releases by explicit tagging. Both approaches are sensible…
    – Mekk
    Commented Jul 30, 2015 at 7:20
  • 1
    … personaly I am on tagging side as it gives me clear right when and why I make release (and allows to publish preliminary versions on trunk, and avoids the need to make feature branches for small code changes, and allows me to use version numbers to signal how big the changes are, and allow me to use human-friendly version numbers). Bottom line: as long as there authors who prefer tagging releases, melpa stable has it's merit – and I’d say there is nothing wrong in author who manage releases by tagging, contrary, that means he or she cares to think when and what should be released.
    – Mekk
    Commented Jul 30, 2015 at 7:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.