From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Installing binaries with package.el Date: Thu, 09 Feb 2017 08:10:58 -0500 Message-ID: References: <3fdcbe78-969e-f9e1-2a9d-a5f8494c35b3@mit.edu> <8760kmtvpu.fsf@mbork.pl> <35ae3a71-f8da-3405-6966-38337d8e74e0@gmail.com> <871svatqh0.fsf@mbork.pl> <76433d89-f381-b805-4501-c9c8b8f7a275@gmail.com> <87d1euniog.fsf@flea> <877f51oklv.fsf@flea> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1486646311 27073 195.159.176.226 (9 Feb 2017 13:18:31 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 9 Feb 2017 13:18:31 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Feb 09 14:18:25 2017 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 1cbocD-0006jH-F4 for ged-emacs-devel@m.gmane.org; Thu, 09 Feb 2017 14:18:25 +0100 Original-Received: from localhost ([::1]:37865 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cbocJ-0006aj-2h for ged-emacs-devel@m.gmane.org; Thu, 09 Feb 2017 08:18:31 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35713) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cboV6-00005Y-Mg for emacs-devel@gnu.org; Thu, 09 Feb 2017 08:11:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cboV3-0005i1-GO for emacs-devel@gnu.org; Thu, 09 Feb 2017 08:11:04 -0500 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:28351) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1cboV3-0005hl-Ak for emacs-devel@gnu.org; Thu, 09 Feb 2017 08:11:01 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CTKQAu3EVY//7rSC1dHAEBBAEBCgEBgzgBAQEBAR+EW4VUnAKXBYYiAoISQxABAgEBAQEBAQFiKIRpAQQBfgsLDQUiEhQYHYkOCK0UKgKLGDGLGYQ7WYUVBY98imqJXAWDDIYzh3olhhWSDzYgeBMOg1wcgXsghnKCOwEBAQ X-IPAS-Result: A0CTKQAu3EVY//7rSC1dHAEBBAEBCgEBgzgBAQEBAR+EW4VUnAKXBYYiAoISQxABAgEBAQEBAQFiKIRpAQQBfgsLDQUiEhQYHYkOCK0UKgKLGDGLGYQ7WYUVBY98imqJXAWDDIYzh3olhhWSDzYgeBMOg1wcgXsghnKCOwEBAQ X-IronPort-AV: E=Sophos;i="5.33,749,1477972800"; d="scan'208";a="292459007" Original-Received: from unknown (HELO pastel.home) ([45.72.235.254]) by smtp.teksavvy.com with ESMTP; 09 Feb 2017 08:10:59 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id A8828657F3; Thu, 9 Feb 2017 08:10:58 -0500 (EST) In-Reply-To: <877f51oklv.fsf@flea> (Ted Zlatanov's message of "Tue, 07 Feb 2017 14:40:28 -0500") X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.181 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:212164 Archived-At: SM> Notice that ELPA packages have always shipped in source form (even the SM> .el files are byte-compiled on the user's machine). So it's only SM> natural to expect dynloaded modules distributed via ELPA to be SM> distributed in source form and compiled during installation. > Help me understand. Say user installs module FOO-1 which binds to > library BAR-1. User upgrades BAR-1 to BAR-2 or uninstalls BAR-1. > What happens? Good question, but that seems unrelated to the issue of how the user gets the compiled version of the module. If she gets it from ELPA somehow (whether compiled locally or not), then we have this problem of detecting and reacting to a change in the underlying OS-provided libraries. Beside the issue of detecting, the "reacting" part should basically re-compile the package, and I think package.el should generally move towards better supporting recompilation of its packages (not just for dynload modules, but also for Elisp), including keeping several compiled versions (in case you want to use the same package with different Emacs versions and we haven't managed to preserve compatibility at the compiled-package level). > What happens to users that don't have a compiler? The way I imagine it working, ELPA packages are basically distributed in source form, and we'd encourage users to compile them locally. We could complement that with a separate repository of precompiled versions of some combinations of package/OS/architecture. > Do you think OS distributions will pick up the module distribution > piece like they did with Python, Perl, etc.? Not sure what you mean. Debian does already provide various ELPA packages, so I guess the answer is yes, but I don't think this will be of much help to the above problems (it just lets the user choose whether to install a package via ELP or via dpkg, and only for those packages which Debian has packaged as a dpkg). IOW, they do a parallel job, which doesn't really help us (not to imply that it hurts, tho). Stefan