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 20:36:14 +0300 Message-ID: <838ttlwodt.fsf@gnu.org> References: <20160916203414.25203.87032@vcs.savannah.gnu.org> <87twcgttjf.fsf@russet.org.uk> <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> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1476812233 13318 195.159.176.226 (18 Oct 2016 17:37:13 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 18 Oct 2016 17:37:13 +0000 (UTC) Cc: Stromeko@nexgo.de, 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 Tue Oct 18 19:37:09 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 1bwYJb-0007bA-PM for ged-emacs-devel@m.gmane.org; Tue, 18 Oct 2016 19:36:39 +0200 Original-Received: from localhost ([::1]:43071 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bwYJd-0008Ey-Jk for ged-emacs-devel@m.gmane.org; Tue, 18 Oct 2016 13:36:41 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42043) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bwYJX-0008Eb-N9 for emacs-devel@gnu.org; Tue, 18 Oct 2016 13:36:36 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bwYJT-0005tb-JG for emacs-devel@gnu.org; Tue, 18 Oct 2016 13:36:35 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:38649) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bwYJT-0005tX-G9; Tue, 18 Oct 2016 13:36:31 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1438 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1bwYJS-0006Op-JC; Tue, 18 Oct 2016 13:36:31 -0400 In-reply-to: <87wph5fw0w.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:208434 Archived-At: > From: phillip.lord@russet.org.uk (Phillip Lord) > Cc: Stromeko@nexgo.de, emacs-devel@gnu.org > Date: Tue, 18 Oct 2016 17:43:11 +0100 > > Org-mode v1 comes with a file called org-html. v1 is distributed with > core emacs. Org-mode v2, however, no longer has a file called org-html, > but does have a file called ox-html. Although org-mode v2 comes in the > path before org-mode v1, it is still possible to load org-html. 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. > 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. > My conclusion: having org-mode its own directory is a good thing. By > extrapolation, therefore, having most or all packages in their own > directory would be a good thing. The extrapolation is invalid, because while Org is a very large package, most other packages aren't. > > If package.el already knows how to unload the old features and load > > the new ones, it will continue doing this for any package, whether in > > or out of core. Right? > > With the example that I have given, this fails at the moment for > org-mode, specificially because org-mode is in core. I don't understand why it fails, but if it's a missing feature in package.el or in the infrastructure, we need to add that, in order to move to having bundled packages on ELPA.