From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Ted Zlatanov Newsgroups: gmane.emacs.devel Subject: Re: Installing binaries with package.el Date: Tue, 07 Feb 2017 14:40:28 -0500 Organization: =?utf-8?B?0KLQtdC+0LTQvtGAINCX0LvQsNGC0LDQvdC+0LI=?= @ Cienfuegos Message-ID: <877f51oklv.fsf@flea> 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> Reply-To: emacs-devel@gnu.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1486496454 22308 195.159.176.226 (7 Feb 2017 19:40:54 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 7 Feb 2017 19:40:54 +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 Tue Feb 07 20:40:51 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 1cbBdC-0005VW-NO for ged-emacs-devel@m.gmane.org; Tue, 07 Feb 2017 20:40:50 +0100 Original-Received: from localhost ([::1]:56103 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cbBdI-00058l-9X for ged-emacs-devel@m.gmane.org; Tue, 07 Feb 2017 14:40:56 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46352) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cbBdB-00058e-J1 for emacs-devel@gnu.org; Tue, 07 Feb 2017 14:40:50 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cbBd8-0003NY-BZ for emacs-devel@gnu.org; Tue, 07 Feb 2017 14:40:49 -0500 Original-Received: from [195.159.176.226] (port=43403 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cbBd7-0003NJ-VA for emacs-devel@gnu.org; Tue, 07 Feb 2017 14:40:46 -0500 Original-Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1cbBcu-0004nV-NK for emacs-devel@gnu.org; Tue, 07 Feb 2017 20:40:32 +0100 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: emacs-devel@gnu.org Original-Lines: 34 Original-X-Complaints-To: usenet@blaine.gmane.org X-Face: bd.DQ~'29fIs`T_%O%C\g%6jW)yi[zuz6; d4V0`@y-~$#3P_Ng{@m+e4o<4P'#(_GJQ%TT= D}[Ep*b!\e,fBZ'j_+#"Ps?s2!4H2-Y"sx" Mail-Copies-To: never Cancel-Lock: sha1:kgAUiuDyjX2r1mwO7QyntHuPdi0= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 195.159.176.226 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:212110 Archived-At: On Tue, 7 Feb 2017 17:58:10 +0100 Aurélien Aptel wrote: AA> Having a support for modules in packages would be cool indeed. But AA> building binaries that work across linux distro is going to be very AA> painful especially since the modules is very likely going to be linked AA> against others libs. So an ELPA like system for pre-built modules is AA> probably not a good idea... I was thinking of a standard OS package repository, e.g. Yum or APT, and a link to that from the ELPA package. Rgeardless, maybe an ELPA package should be able to declare its dependency on specific OS packages. This could be useful even if the package doesn't have binaries or modules. AA> I think it's best to stick to compiling them on the user machine. AA> Which is also tricky to get right obviously. On Tue, 07 Feb 2017 12:45:54 -0500 Stefan Monnier wrote: 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? What happens to users that don't have a compiler? Do you think OS distributions will pick up the module distribution piece like they did with Python, Perl, etc.? Ted