From mboxrd@z Thu Jan 1 00:00:00 1970 From: phillip.lord@russet.org.uk (Phillip Lord) Subject: Re: Remove Org from Emacs repository? Date: Tue, 20 Dec 2016 10:13:04 +0000 Message-ID: <87r3526h8v.fsf@russet.org.uk> References: <871sx5pp6u.fsf@laptoptop.i-did-not-set--mail-host-address--so-tickle-me> <87shpkyzcy.fsf@Rainer.invalid> <87lgvbrgd6.fsf@russet.org.uk> <87oa07zr6r.fsf@Rainer.invalid> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:35756) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cJHQ2-00040q-TT for emacs-orgmode@gnu.org; Tue, 20 Dec 2016 05:13:15 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cJHPy-0003ui-7x for emacs-orgmode@gnu.org; Tue, 20 Dec 2016 05:13:14 -0500 Received: from mailgw.mycpanelcloud.co.uk ([185.116.214.213]:60142) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1cJHPx-0003tk-O5 for emacs-orgmode@gnu.org; Tue, 20 Dec 2016 05:13:10 -0500 Received: from localhost (localhost [127.0.0.1]) by mailgw.mycpanelcloud.co.uk (Postfix) with ESMTP id 04007C4084 for ; Tue, 20 Dec 2016 10:12:44 +0000 (GMT) Received: from mailgw.mycpanelcloud.co.uk (localhost [127.0.0.1]) by mailgw.mycpanelcloud.co.uk (Postfix) with ESMTP id AC173C40D0 for ; Tue, 20 Dec 2016 10:12:43 +0000 (GMT) Received: from cloud103.planethippo.com (unknown [31.216.48.128]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mailgw.mycpanelcloud.co.uk (Postfix) with ESMTPS id 979A6C4084 for ; Tue, 20 Dec 2016 10:12:43 +0000 (GMT) In-Reply-To: (Achim Gratz's message of "Mon, 19 Dec 2016 19:53:16 +0100") List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: "Emacs-orgmode" To: Achim Gratz Cc: emacs-orgmode@gnu.org Achim Gratz writes: > Phillip Lord writes: >> I think there's only a few problems, actually. package.el initialization >> is all or nothing at the moment, and is disabled on emacs -q. Neither of >> these would make sense if we wanted in built packages. > > My opinion is that unless package.el adds explicit support for > system-level packetization decisions (i.e. for admins or distributions) > it's not going to gain widespread support from that small, but important > set of folks. I think it mostly has this, in the sense that you can add packages into admin installation locations. Although, this are disabled with emacs -Q. > Of course the user will then have to be able to override these like > deactivation of packages, installing different versions, etc. Different versions you can do. Deactivation at the moment, no, although I guess you could delete the autoloads. > Before long it also needs to be able to cope with different package > archives simultaneously especially when those have incompatible > numbering schemes. That one would be a bit harder, although you could add support for package repositories to add their own numbering scheme by installating a package. > >> It's not strictly necessary, though. The current idea is to not to use >> packages but to, essentially, move the lisp of packages in ELPA into >> place in the build. package.el need not be involved then. > > Yes I know. Which is in essence prolonging the current state of affairs > as far as the users are concerned. If it gets things moving into the > right direction I'll be glad. I just had hoped for some more general > (some would say radical) solution. Some did say radical, unfortunately. Still, you give me encouragement. I may complete my solution after all. Perhaps combined with a completely repackaged Emacs core. Phil