Subject: bug#14632: 24.3.50; package-install-p returns nil after package-install

From: Sebastian Wiesner <[email-masked]>
Date: Sun, 16 Jun 2013 10:47:47 +0200

After "package-install", "package-installed-p" still returns nil for
the package that was just installed.  Consider:

ELISP> (package-installed-p 'nrepl)
nil
ELISP> (package-install (cdr (assq 'nrepl package-archive-contents)))
nil
ELISP> (package-installed-p 'nrepl)
nil
ELISP> (package-initialize)
t
ELISP> (package-installed-p 'nrepl)
t

Also, before "package-initialize", the newly installed "nrepl" package
still only appears as "available" in "M-x list-packages", but not as
"installable".

Even worse, dependency resolution is broken, likely as a result of this
misbehavior of "package-installed-p".  Consider "hardhat" and
"ignoramus", where "hardhat" depends on "ignoramus".  If I explicitly
install "ignoramus", "hardhat" cannot be installed afterwards:

ELISP> (package-installed-p 'ignoramus)
nil
ELISP> (package-installed-p 'hardhat)
nil
ELISP> (cdr (assq 'hardhat package-archive-contents))
[cl-struct-package-desc hardhat
                        (20130522 1243)
                        "Protect against clobbering user-writable
files [github]"
                        ((ignoramus
                          (0 6 2)))
                        single "melpa" nil]

ELISP> (package-install (cdr (assq 'ignoramus package-archive-contents)))
nil
ELISP> (package-install (cdr (assq 'hardhat package-archive-contents)))
*** Eval error ***  File exists:
/Users/swiesner/.emacs.d/elpa/ignoramus-20130522.1245/ignoramus-pkg.el
ELISP> (package-initialize)
t
ELISP> (package-installed-p 'ignoramus)
t
ELISP> (package-install (cdr (assq 'hardhat package-archive-contents)))
nil

As you can see, when installing "hardhat", package.el still attempts
to install ignoramus though this package is already installed.  Only
after re-initializing package.el, the ignoramus installation is
detected, and hardhat can be installed.

The packages mentioned in this mail are from the MELPA archive [1],
simply because I hit this bug with these packages, and was too lazy to
reproduce it with packages from the GNU ELPA archive.  I don't think
that the archive matters, though.

[1]: http://melpa.milkbox.net/