Emacs' package.el
always downloads the highest versioned package it can find, and I don't know a way to stop it from doing so, in general. You can, however, specify which repository your package comes from, using the package-pinned-packages
variable, available through the customization menu for Emacs >= 24.4. I use it to "pin" packages I use to MELPA Stable rather than MELPA, for example. If you don't, and you update, say, zenburn-theme
, you will always get zenburn-theme
version 20151003.2346 (or whatever version is most current) in MELPA rather than version 2.2 (today's most current) from MELPA Stable. (I have both archives in my package-archives
list.) This way I at least can make Emacs stick to something a package author has marked as a stable version, not the latest commit he or she has made to Github.
This helps with versioning to a small degree, but doesn't really answer your question, since you are trying to keep package.el
from downloading anything that will shadow your built-in package. Unfortunately, package-pinned-packages
will only let you specify a repository listed in package-archives
. Emacs' "built-in" package archive isn't listed there, at least on my Emacs 24.5, so that isn't an option for your situation. (Emacs maintainers: how about putting a "built-in" archive in there by default?)
You say you have a function for batch install of all packages, so presumably you don't mind writing a little lisp code. Emacs 24.5 (and maybe earlier) package.el
has a function package-built-in-p
which will let you test whether a package is built in or not. From the documentation,
Return true if PACKAGE is built-in to Emacs. Optional arg MIN-VERSION,
if non-nil, should be a version list specifying the minimum acceptable
version.
This lets you specify a minimum acceptable version, but not a maximum acceptable version, or even (I wish) a particular version. You can use it to determine whether a package in your batch list is built-in or not, and exclude it from your list if it is. Or you could just exclude it from your list and uninstall the version you already have in your elpa
directory, as a previous poster suggested.
You could set up your own local
package archive, put your preferred version in there, and pin your package to local
. This way you get total control over the versioning. See How can I set up an Elpa server? for directions. Now that I think about it, this may be a good idea for many reasons...
(require 'cl-lib)
?require
statement just above the package installation code, however, this did not solve the problem.