Updating packages in Emacs - emacs

Question

I have the following setup for packages (not sure if there is a better recommended one):
(require 'package)
(setq package-archives '(("ELPA" . "http://tromey.com/elpa/")
("gnu" . "http://elpa.gnu.org/packages/")
("marmalade" . "http://marmalade-repo.org/packages/")))
; Apparently needed for the package auto-complete (why?)
(add-to-list 'package-archives
'("melpa" . "http://melpa.milkbox.net/packages/") t)
(package-initialize)
(setq url-http-attempt-keepalives nil)
I have three questions related to the installation and updating of packages.
Q1. Is there a way to update the list of available packages (and most recent versions) and update a specific package?
Q.2 What is the difference between the following package sources?:
ELPA,
GNU
marmalade
melpa
Q.3 Does it matter the order in which they are added to package-archives?

Answer 1

In order to automatically update the list of packages, only if there is no package list already, use the following:
(when (not package-archive-contents)
(package-refresh-contents))
In order to update all installed packages, type package-list-packages, which will take you to the *Packages* buffer (and also update the list of packages), and then type U x.
package-refresh-contents unconditionally tries to download a package list from all repos you've added to package-archives; package-archive-contents is non nil if you have already downloaded the package list.
ELPA is the original. I don't think it's really maintained anymore, but I'm not sure. I don't use it.
GNU is "official". It's maintained along with Emacs, which means things should always work but updates and new packages don't come very often.
Marmalade is basically a website where you can upload a complete package, and it will be added to the marmalade repo. You don't just submit a link to the package's upstream, and it doesn't quite automate the creation of the package completely. I think this is the Right Thing, because you don't necessarily want to track upstream. Unfortunately, it has been unmaintained for a while, but someone recently took it over so it should be back and better at some point.
Melpa takes a URL to e.g. the EmacsWiki lisp area or a github repo, and builds a package automatically from it. Thus it is usually at most a day behind whatever it is tracking. Although it tracks upstream, I've never had a problem in practice, and this is where most of my packages are from. There is also Melpa Stable, which is like Melpa but grabs tagged revisions of the upstream repo instead of the latest revision. Melpa stable has fewer packages than Melpa.
Org mode has its own package.el repo (http://orgmode.org/elpa/).
All of the package repos work the same, you just add them to your package-archives.
Here's a more in-depth blog post about this subject, which I mostly agree with.
I'm not sure, but I think if a package is duplicated in different repos, the order the repos appear in in package-archives determines precedence. I don't know if higher precedence is at the beginning or end of the list.
Update: In Emacs 25, there is a variable package-archive-priorities that you can use to prioritize your package repos (e.g. prefer ELPA over MELPA).
Here is the relevant section of my init.el, if you're interested:
(setq jpk-packages
'(
ac-dabbrev
...
yasnippet
))
(package-initialize)
(add-to-list 'package-archives
'("melpa" . "http://melpa.org/packages/"))
(add-to-list 'package-archives
'("org" . "http://orgmode.org/elpa/"))
;; install any packages in jpk-packages, if they are not installed already
(let ((refreshed nil))
(when (not package-archive-contents)
(package-refresh-contents)
(setq refreshed t))
(dolist (pkg jpk-packages)
(when (and (not (package-installed-p pkg))
(assoc pkg package-archive-contents))
(unless refreshed
(package-refresh-contents)
(setq refreshed t))
(package-install pkg))))
(defun package-list-unaccounted-packages ()
"Like `package-list-packages', but shows only the packages that
are installed and are not in `jpk-packages'. Useful for
cleaning out unwanted packages."
(interactive)
(package-show-package-list
(remove-if-not (lambda (x) (and (not (memq x jpk-packages))
(not (package-built-in-p x))
(package-installed-p x)))
(mapcar 'car package-archive-contents))))

Answer 2

Within Emacs, use M-x list-packages to list all packages which will automatically refresh the archive contents. Afterwards use U to mark all upgradable packages to be upgraded, and x to actually perform the new updates. Emacs will then fetch and install all upgrades, and ask you to whether to remove the old, obsolete versions afterwards.
You may also want to take a look at Carton which provides a more convenient way to manage your packages by declaring them in a dedicated file, and includes a convenient command line client to automatically install and upgrade packages declared in this way.
The order of package-archives does not matter. Emacs aggregates the contents of all archives into a single coherent list of available packages and their versions, stored in package-archive-contents.
Upon package-install, Emacs will simply pick the newest version of a package, regardless of the originating archive. For more control about package origin, MELPA provides the melpa package which allows to black- or whitelist packages from specified archives.

Answer 3

In terminal:
emacs
M-x list-packages
this puts you in the *packages* buffer
shift-u x
emacs will ask you (y/n), wait for updates
C-x k <ret>
this will kill the *packages* buffer and return you back to *scratch*
C-x-C-c
this will exit emacs, and let you relaunch via, but you might have to debug :(
emacs
my 2¢

Answer 4

This is more of an extended comment on jpkotta's answer.
This is an adjustment I am experimenting with for jpkotta's answer above:
(setq n 0) ; set n as 0
(dolist (pkg pkgs-2b-present) ; for each pkg in list
(unless (or ; unless
(package-installed-p pkg) ; pkg is installed or
(assoc pkg ; pkg is in the archive list
package-archive-contents))
(setq n (+ n 1)))) ; add one to n
(when (> n 0) ; if n > 0,
(package-refresh-contents)) ; refresh packages
(replacing (when (not package-archive-contents) (package-refresh-contents))).
The package-list was not refreshing sufficiently often enough for my use-case.
I haven't considered if there is a more efficient solution to my problem; first, I've to see if the problem goes away with this adjustment.