From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ted Zlatanov Newsgroups: gmane.emacs.devel Subject: Re: GnuTLS for W32 Date: Mon, 02 Jan 2012 17:35:21 -0500 Organization: =?utf-8?B?0KLQtdC+0LTQvtGAINCX0LvQsNGC0LDQvdC+0LI=?= @ Cienfuegos Message-ID: <87ipktag2e.fsf@lifelogs.com> References: <87aa68dfao.fsf@lifelogs.com> <87ty4fbje8.fsf@lifelogs.com> <83ehvjs8t5.fsf@gnu.org> <87pqf3bcom.fsf@lifelogs.com> <83boqns68o.fsf@gnu.org> <87liprazr1.fsf@lifelogs.com> <83wr9bqez3.fsf@gnu.org> <87y5tr9dwv.fsf_-_@lifelogs.com> <87k45alwgb.fsf@wanadoo.es> <87fwfyltm1.fsf@wanadoo.es> <87boqmlrma.fsf@wanadoo.es> <87ty4e9j19.fsf@lifelogs.com> <83obumqa0v.fsf@gnu.org> Reply-To: emacs-devel@gnu.org NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: dough.gmane.org 1325543753 7883 80.91.229.12 (2 Jan 2012 22:35:53 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 2 Jan 2012 22:35:53 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jan 02 23:35:49 2012 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1RhqTr-0005Kr-DV for ged-emacs-devel@m.gmane.org; Mon, 02 Jan 2012 23:35:47 +0100 Original-Received: from localhost ([::1]:46362 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RhqTq-00068K-WF for ged-emacs-devel@m.gmane.org; Mon, 02 Jan 2012 17:35:47 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:52392) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RhqTm-000684-L6 for emacs-devel@gnu.org; Mon, 02 Jan 2012 17:35:43 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RhqTl-0000s6-5u for emacs-devel@gnu.org; Mon, 02 Jan 2012 17:35:42 -0500 Original-Received: from lo.gmane.org ([80.91.229.12]:55362) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RhqTk-0000rv-OZ for emacs-devel@gnu.org; Mon, 02 Jan 2012 17:35:41 -0500 Original-Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1RhqTj-0005HD-Io for emacs-devel@gnu.org; Mon, 02 Jan 2012 23:35:39 +0100 Original-Received: from c-76-28-40-19.hsd1.vt.comcast.net ([76.28.40.19]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 02 Jan 2012 23:35:39 +0100 Original-Received: from tzz by c-76-28-40-19.hsd1.vt.comcast.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 02 Jan 2012 23:35:39 +0100 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: emacs-devel@gnu.org Original-Lines: 75 Original-X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: c-76-28-40-19.hsd1.vt.comcast.net 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 User-Agent: Gnus/5.110018 (No Gnus v0.18) Emacs/24.0.90 (gnu/linux) Cancel-Lock: sha1:x+4bHRIxgOpRdiQWvZBeLopTxG0= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 80.91.229.12 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:147200 Archived-At: On Mon, 02 Jan 2012 19:39:12 +0200 Eli Zaretskii wrote: >> From: Ted Zlatanov >> Date: Mon, 02 Jan 2012 11:16:34 -0500 >> >> In any case, it's better to have the *ability* to issue updates than >> not to. In that context, it seems more sensible to package GnuTLS >> support as an ELPA package so it can be upgraded without upgrading >> Emacs as a whole. EZ> It makes sense, but how is ELPA easier than any other download EZ> address? All that's needed is to download a single zip archive and EZ> unzip it. Why does it matter if it comes from ELPA or from EZ> elsewhere? ELPA updates can be done entirely from within Emacs. Downloading and unzipping a file is a nuisance. Imagine if you asked GNU/Linux users to do the same. "But they have package managers..." Exactly! And so does Emacs, now that package.el is here! So let's use packages for non-trivial work. >> So perhaps we just need a versioned "gnutls-w32" ELPA package to >> DTRT. W32 users can choose to install it or it can be installed by >> default, whichever we or the distribution decides. EZ> The alternatives are: EZ> . have GnuTLS as part of the binary zip EZ> . have GnuTLS as a separate zip alongside the binary zip (we do this EZ> for libxpm) EZ> . have GnuTLS available for download from some other address I think the right solution is to ask the user "you don't have the GnuTLS package for W32, do you want to get it?" and then do it through ELPA, when they try to use HTTPS for instance. The same, actually, should be done with libxpm and any other add-on DLLs. So this work could become much more useful than just for GnuTLS. Can Emacs modify the DLL search path on W32 so it can install some DLL from ELPA and then activate it dynamically? Or does it require a restart and modifying the global PATH? Either way, can the process be automated? On Mon, 2 Jan 2012 18:31:24 +0100 Juanma Barranquero wrote: JB> 2012/1/2 Ted Zlatanov : >> I stated I would do that monitoring.  In any case, it's better to have >> the *ability* to issue updates than not to. JB> We already have the ability to issue updates, because any update is JB> just getting the info to the user (whether they download a binary JB> tarball from us or somewhere else, the only real trouble is getting JB> the user to know that there's a security issue to be fixed in the JB> first place). In that regard, announcing a new release or announcing JB> that the user should upgrade their GnuTLS binary is largely JB> irrelevant. ELPA, however, can show the user all the packages that need to be updated in one place, so they don't have to check for GnuTLS updates on W32 specifically. It should be set up to check on startup, IMHO. That's a win (heh heh) for everyone, and fits with what users expect nowadays, compared with other extensible software like Firefox and Chrome. JB> But anyway, the issue is not just monitoring. Someone has to build JB> updated binary GnuTLS packages for Windows. That Eli just did it does JB> not mean we can burden him with the task forever. We can automate that. Eli and Nicos have done the hard part, I think. Ditto for an ELPA package, if we can do it once it can be automated. Ted