From: Jean-Christophe Helary <email@example.com>
To: Org-mode <firstname.lastname@example.org>, Emacs developers <email@example.com>
Subject: Re: org 9.2.6 and org 9.1.9
Date: Wed, 27 Nov 2019 12:13:51 +0900 [thread overview]
Message-ID: <DD9FC15D-B08D-449E-AA0E-493AEA1B7743@traduction-libre.org> (raw)
> On Nov 27, 2019, at 11:59, Cook, Malcolm <MEC@stowers.org> wrote:
> Yes, it is a bit of dependency hell.
I see 2 solutions here:
1) org is only provided as a built-in package and updated there when necessary
2) org is removed from the built in packages
The current situation is really weird.
> Quoting myself from Re: [O] How to safely update from ver. 8.2.10 to 8.3.x :
> Here's what I do, at the shell:
> emacs -Q -batch -eval "(progn (require 'package) (add-to-list
> 'package-archives '(\"org\" . \"http://orgmode.org/elpa/\";))
> (package-initialize) (package-refresh-contents) (package-install
> This assures that org is not already loaded when org is compiled, which I've
> learned is the source of creating a mess.
> Note: I use org-plus-contrib from melpa instead of org. If you want just org,
> you could simply:
> emacs -Q -batch -eval "(progn (require 'package) (package-initialize)
> (package-refresh-contents) (package-install 'org-plus-contrib))"
> From: Emacs-orgmode <firstname.lastname@example.org> On Behalf Of Tim Cross
> Sent: Tuesday, November 26, 2019 3:41 PM
> To: Nick Dokos <email@example.com>
> Cc: Org-mode <firstname.lastname@example.org>; Emacs developers <email@example.com>
> Subject: Re: org 9.2.6 and org 9.1.9
> CAUTION: This email was received from an External Source
> There is a very important rule which must be followed wrt org-mode installation. It is critical that no version of org is already loaded before installing a new version. This can be quite tricky as many of us have org setups which automatically load some org functionality without explicitly opening an org file or agenda view (for example, you might be using an org add-on for email). Situation is worse if we are loading org as part of our init.el.
> I'm also not sure that tweaking the load-path order is sufficient if your installing org via M-x package-install as there is a 'chicken and egg' problem with the initial install. If your init.el file is loading org functionality and you only have the built-in org version installed, that version will be loaded before you run package-install. Probably works if you install via your init.el though.
> I've found the safest thing to do is only use autoload or use-package with deferred loading for org and whenever updating org (I use the org-plus-contrib package from the org elpa repo) only update immediately after a fresh restart of emacs and before doing anything else. Failing to do this often results in a broken build as you get a set of new org elc files which contains definitions from two different org versions. When the versions are only different in minor version numbers, this mixed build may not even be noticeable, but when major version differences exist, you get the symptom of broken functionality, missing definitions or unbound symbols.
> The situation is made worse by package maintainers specifying the latest org version rather than the version built into Emacs when the bundled version would be sufficient.
> It took me a while to structure my init.el file such that no org functionality was loaded until I used something which depends on it. However, once I did, provided I only update org in a fresh new session, all works flawlessly. I found use-package package really helped with this.
> On Wed, 27 Nov 2019 at 06:22, Nick Dokos <firstname.lastname@example.org> wrote:
> Jean-Christophe Helary <email@example.com> writes:
> > org 9.1.9 is a built-in
> > but org 9.2.6 comes as a dependency to some packages and having both installed creates conflicts.
> What conflicts are you seeing? I have the built-in 9.1.9 org that
> comes with emacs but I run (close to) latest master and I see no
> problems: the only thing I do is to set my load-path to point to the
> right place (and make sure that that setting precedes the
> /usr/local/share/emacs/27.0.50/lisp/org setting that emacs adds):
> (add-to-list 'load-path (expand-file-name "~/elisp/org-mode/lisp"))
> Although that has been enough for me, it's probably safer to delete
> from load-path all other org entries, thereby making the built-in
> version invisible to emacs - in my case, I just have the one:
> (delete "/usr/local/share/emacs/27.0.50/lisp/org" load-path)
> That way, if you happen to do something like `(require 'old-org-req)'
> with a requirement that is not satisfied by current org, but is
> satisfied by the built-in org, you'd get an error, rather than getting
> a mixed installation.
> > Why does that happen ?
> > Can't 9.2.6 override 9.1.9 ? It's not the first time I have issues
> > with that situation and that's extremely confusing. What is the best
> > way to solve that ?
> I think the above should be enough (and IME it is), but maybe someone can
> think of other things that might trip one up.
> "There are only two hard problems in computer science: cache
> invalidation, naming things, and off-by-one errors." -Martin Fowler
> Tim Cross
next prev parent reply other threads:[~2019-11-27 3:13 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-24 13:37 Jean-Christophe Helary
2019-11-26 19:15 ` Nick Dokos
2019-11-26 21:41 ` Tim Cross
2019-11-27 2:59 ` Cook, Malcolm
2019-11-27 3:13 ` Jean-Christophe Helary [this message]
2019-11-27 6:18 ` Stefan Kangas
2019-11-27 13:23 ` Stefan Monnier
2019-11-27 17:20 ` Cook, Malcolm
2019-11-27 21:51 ` Tim Cross
2019-11-27 22:01 ` Stefan Monnier
2019-11-26 23:14 ` Jean-Christophe Helary
2019-11-27 3:24 ` Stefan Monnier
2019-11-27 5:43 ` Jean-Christophe Helary
2019-11-27 6:00 ` Tim Cross
2019-11-27 6:29 ` Stefan Kangas
2019-11-27 6:42 ` Tim Cross
2019-11-27 10:11 ` Stefan Kangas
2019-11-27 13:21 ` Stefan Monnier
2019-11-27 15:44 ` Eli Zaretskii
2019-11-27 7:04 ` Fraga, Eric
2019-11-27 6:34 ` Stefan Kangas
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).