From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: feature/integrated-elpa 4f6df43 15/23: README added Date: Wed, 19 Oct 2016 20:59:52 +0300 Message-ID: <83funsusmf.fsf@gnu.org> References: <20160916203414.25203.87032@vcs.savannah.gnu.org> <83d1j33qgg.fsf@gnu.org> <87wph96cto.fsf@russet.org.uk> <831szh3iq4.fsf@gnu.org> <87mvi5spl9.fsf@Rainer.invalid> <83mvi51y3b.fsf@gnu.org> <87instslxu.fsf@russet.org.uk> <83inst1vut.fsf@gnu.org> <87eg3ekjz2.fsf@russet.org.uk> <83vawpx677.fsf@gnu.org> <87h989ixxd.fsf@russet.org.uk> <83mvi1ww6m.fsf@gnu.org> <87wph5fw0w.fsf@russet.org.uk> <838ttlwodt.fsf@gnu.org> <878ttl3342.fsf@Rainer.invalid> <8360opwjs2.fsf@gnu.org> <8760oosrn8.fsf@russet.org.uk> <83shrsvj3g.fsf@gnu.org> <86twc8r8gw.fsf@realize.ch> <83r37cvfo6.fsf@gnu.org> <87funsfk0r.fsf@russet.org.uk> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1476900305 3954 195.159.176.226 (19 Oct 2016 18:05:05 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 19 Oct 2016 18:05:05 +0000 (UTC) Cc: Stromeko@nexgo.de, a.s@realize.ch, emacs-devel@gnu.org To: phillip.lord@russet.org.uk (Phillip Lord) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Oct 19 20:05:01 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bwvEQ-0007fD-Ip for ged-emacs-devel@m.gmane.org; Wed, 19 Oct 2016 20:04:50 +0200 Original-Received: from localhost ([::1]:50126 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bwvES-0003U5-Md for ged-emacs-devel@m.gmane.org; Wed, 19 Oct 2016 14:04:52 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58105) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bwv9v-0000h1-13 for emacs-devel@gnu.org; Wed, 19 Oct 2016 14:00:14 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bwv9s-0006ur-17 for emacs-devel@gnu.org; Wed, 19 Oct 2016 14:00:11 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:56654) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bwv9r-0006uY-SH; Wed, 19 Oct 2016 14:00:07 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:3810 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1bwv9q-0002qc-Tg; Wed, 19 Oct 2016 14:00:07 -0400 In-reply-to: <87funsfk0r.fsf@russet.org.uk> (phillip.lord@russet.org.uk) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:208484 Archived-At: > From: phillip.lord@russet.org.uk (Phillip Lord) > Cc: Alain Schneble , Stromeko@nexgo.de, emacs-devel@gnu.org > Date: Wed, 19 Oct 2016 16:14:44 +0100 > > > The new version of Org will never do that. So you are talking about > > other packages that were not yet updated to follow suit, is that > > right? If so, is such explicit loading allowed? If it's allowed, > > it's a separate problem of dependencies between packages, and should > > exist with any arrangement of directories, I think. > > org has many add on packages, which do use explicit "require" forms to > internal packages (if, for example, they extend an existing org > backend). Please see above: the problem is not within a single package, because any package will always maintain internal requires in order. > What I would expect is that an explicit (require 'org-html) would fail > (i.e. report an error) when upgrading org to a version that does not > include org-html. What actually happens is org-html from the old version > gets loaded. There should be no (require 'org-html) inside Org files in an Org version that doesn't include org-html. > load-path shadowing is I think, an ineffective mechanism for isolation > between versions. Deleting old versions would work but not for core, > admin installed, packages and is not-revertable. Which is why load-path shadowing is the mechanism we should use, all its disadvantages notwithstanding. > Removing old versions from load-path is clean and the best solution, > which is why package.el uses is. That solution won't work with files in core.