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: Tue, 18 Oct 2016 22:15:41 +0300 Message-ID: <8360opwjs2.fsf@gnu.org> References: <20160916203414.25203.87032@vcs.savannah.gnu.org> <86a8e7symk.fsf@realize.ch> <8737jzl4u9.fsf@russet.org.uk> <8337jz8dg8.fsf@gnu.org> <83insv3tnl.fsf@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> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1476818241 15929 195.159.176.226 (18 Oct 2016 19:17:21 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 18 Oct 2016 19:17:21 +0000 (UTC) Cc: emacs-devel@gnu.org To: Achim Gratz Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Oct 18 21:17:17 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 1bwZss-0002da-7C for ged-emacs-devel@m.gmane.org; Tue, 18 Oct 2016 21:17:10 +0200 Original-Received: from localhost ([::1]:43421 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bwZsu-0004tJ-CG for ged-emacs-devel@m.gmane.org; Tue, 18 Oct 2016 15:17:12 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41289) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bwZrs-0004s9-SC for emacs-devel@gnu.org; Tue, 18 Oct 2016 15:16:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bwZrn-0001EF-TA for emacs-devel@gnu.org; Tue, 18 Oct 2016 15:16:08 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:39684) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bwZrn-0001E5-PP; Tue, 18 Oct 2016 15:16:03 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1613 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1bwZrm-0000oT-Go; Tue, 18 Oct 2016 15:16:03 -0400 In-reply-to: <878ttl3342.fsf@Rainer.invalid> (message from Achim Gratz on Tue, 18 Oct 2016 20:48:29 +0200) 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:208441 Archived-At: > From: Achim Gratz > Date: Tue, 18 Oct 2016 20:48:29 +0200 > > Eli Zaretskii writes: > > That just means installing a new version needs to remove the previous > > version's files first, that's all. It has nothing to do with > > load-path. > > That's simply not an option when a user wants to install an updated ELPA > package in his home directory while the system administrator keeps the > Emacs installation as-distributed. In other words, you'd kill _the_ > feature that package.el was supposed to give mere users and arguably the > main selling point. If no better solution comes up, it would mean the user will have to restart Emacs. Hardly a catastrophe. > >> Org-mode v1 comes with org-html. v1 is distributed through ELPA. > >> Org-mode v2 comes with ox-html. We upgrade v1 to v2, and v1 is removed > >> from the path. org-html is no longer loadable. > > > > org-html doesn't need to be loadable if it doesn't exist in the new > > version. Again, nothing to do with load-path. > > But in the situation explained by Phillip it _is_ loadable, even though > it must not be. If in fact you have an autoload pointing to a file that > no longer exists or doesn't contain the autoloaded function anymore, > then a modification of load-path after that autoload has been generated > won't help at all. Restarting Emacs will solve that. > Well, start with cleaning up load-path and autoloads in a way that any > built-in package can be cleanly deactivated: after deactivation Emacs > behaves as if the package wasn't present. > > If you think you don't need this, I have done some experiments to excise > the remnants of a built-in package from Emacs' data structures > (autoloads and customization), but there really isn't any supported way > to do that and I consider the whole thing incredibly brittle since I > need to manipulate internal data structures to do that. At the minimum > you'd need official support for re-defining an autoload so it stops > pointing at the wrong load-file. These problems need to be attacked and solved. But saying that instead of solving them we should fundamentally change our lisp/ tree is IMO not the right way. It's akin to searching the keys where the streetlight is, not where they were lost. We need to define the goal, and then work towards implementing it, not the other way around.