4

I'm having problems installing package from (m)elpa which require cl-lib-1.0.

My emacs version is 24.3, hence I have a builtin copy of cl-lib-1.0, however, the only version available via elpa is 0.5. Unfortunately the dependency resolution does not seem to understand that my builtin cl-lib is more recent (and adequate), hence it installs cl-lib in v0.5.

The packages in question are shift-text and stripe-buffer available on melpa.

I'm using a function for batch install of all packages, you can find the relevant code here.

A working (workaround) solution is to uninstall cl-lib-0.5 via list-packages and then manually install the package(s) in question. [Therefore I think the actual culprit is my batch install routine?] However, I'd like to continue using my batch installation procedure, hence the question

How do you tell package.el that a certain package is already installed in a given version?

Edit: Btw, this problem has surfaced previously, however, the discussion in this github issue does not properly solve it.

  • As a test could you try adding an explicit call to (require 'cl-lib)? – Jonathan Leech-Pepin Oct 2 '14 at 11:46
  • @JonathanLeech-Pepin I added the require statement just above the package installation code, however, this did not solve the problem. – elemakil Oct 2 '14 at 12:58
5

The version of cl-lib in GNU Elpa is a backport of the cl-lib from Emacs 24.3 intended for Emacs <=24.2. (Or put differently it is a forward compatibility wrapper around cl as it comes with <=24.2). If you are using Emacs 24.3 then you don't need it and when you use package.el from that Emacs version it will never install any version of cl-lib because it is aware that that is a built-in library/package.

So just uninstall cl-lib, you probably installed it when still using an older Emacs version. If package.el actually tries to install cl-lib while using Emacs 24.3, then you have to investigate why that happens, it shouldn't.

The second issue is that the mentioned packages depend on version 1.0 of cl-lib when they should instead depend on 0.5 so that they can be used with older Emacsen. If they cannot be used with older Emacsen that should be made explicit by depending on (emacs "24.3"). Please open issues against these packages so that this can be fixed.

  • cl-lib is reinstalled in v0.5 at every startup, that is the whole point... I suspect that my batch install code is at fault, however, I have not clue why / how. – elemakil Oct 2 '14 at 13:00
  • Is cl-lib explicitly listed in the part you elided (;; [...] other packages)? – tarsius Oct 2 '14 at 13:25
  • It was not. But you put me on the right track. I was modifying that list at another point and that added a stray cl-lib. Reverting the list to its original value stopped the installation of cl-lib. It appears that while debugging the human error became the true bug ;-). – elemakil Oct 2 '14 at 13:36
  • Hehe. Also package.els dependency handling is very rudimentary. All it understands is at least version V of package X, something more elaborate like exactly version V ain't possible. That is a limitation in package.el but I don't think that it would do much good to support this at this point anyway, not until Emacs has modules; what if Y depends on =X-1 while Z depends on >=X-2? So this forces authors of Y and Z to always support the latest version of X which isn't necessarily a bad thing. But it would be useful if package.el refused to install multiple versions of the same p. – tarsius Oct 2 '14 at 13:47
0

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...

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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