From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: GnuTLS for W32 Date: Tue, 03 Jan 2012 02:14:19 -0500 Message-ID: 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> <87ipktag2e.fsf@lifelogs.com> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: dough.gmane.org 1325574870 3969 80.91.229.12 (3 Jan 2012 07:14:30 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 3 Jan 2012 07:14:30 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jan 03 08:14:26 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 1RhyZl-0002TQ-Mh for ged-emacs-devel@m.gmane.org; Tue, 03 Jan 2012 08:14:25 +0100 Original-Received: from localhost ([::1]:52737 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RhyZk-0006Ps-KZ for ged-emacs-devel@m.gmane.org; Tue, 03 Jan 2012 02:14:24 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:40239) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RhyZh-0006Pn-VP for emacs-devel@gnu.org; Tue, 03 Jan 2012 02:14:23 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RhyZg-0008Kz-2f for emacs-devel@gnu.org; Tue, 03 Jan 2012 02:14:21 -0500 Original-Received: from fencepost.gnu.org ([140.186.70.10]:46611) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RhyZg-0008Kv-1B for emacs-devel@gnu.org; Tue, 03 Jan 2012 02:14:20 -0500 Original-Received: from eliz by fencepost.gnu.org with local (Exim 4.71) (envelope-from ) id 1RhyZf-0007ZS-UL for emacs-devel@gnu.org; Tue, 03 Jan 2012 02:14:19 -0500 In-reply-to: <87ipktag2e.fsf@lifelogs.com> (message from Ted Zlatanov on Mon, 02 Jan 2012 17:35:21 -0500) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 140.186.70.10 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:147204 Archived-At: > From: Ted Zlatanov > Date: Mon, 02 Jan 2012 17:35:21 -0500 > > 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. See below: currently, using this for anything not Lisp-based, like installing a new dynamic library, is a pipe dream. (Actually, even downloading a new version of a Lisp library into a running session has its problems, as discussed here recently; but I digress.) > 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! And I thought only Windows users were spoiled enough to demand one-click installations. "Downloading and unzipping is a nuisance"... sheesh. > 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? We currently lack infrastructure to replace a DLL that is already used by a running Emacs process. The code that loads a DLL and initializes the function pointers used to access its APIs assumes this will be done only once in a given session, so currently we do need a restart. To be able to replace a DLL without restarting Emacs, we would need to add code to free and unload a used DLL from the Emacs process, and then load the new one. This might be complicate if there are data structures lying around that use the DLL facilities, like an existing connection using GnuTLS or an image displayed using an image DLL. We will need to shut down the relevant Emacs features before replacing the DLL. There will also be complications with this if another Emacs process runs the same binary and uses the same DLL, because I don't think you can overwrite the DLL from under the feet of that other process. If you are thinking about a limited goal of installing for the first time a DLL that does not yet exist and is not loaded into Emacs, then it can be done, although some code will need to be written for that as well, and I'm not sure package.el is designed to handle such "packages". Moreover, I'm not sure such a limited goal would be in the spirit of package managing, since upgrading an installed package is an important part of that, perhaps more important than the initial installation. > 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. Who exactly are "we" in this sentence? > Eli and Nicos have done the hard part, I think. I did nothing of the kind. I just configured and built the stock distribution, and fought whatever problems I found that prevented the build and the test suite to run to completion. The record of that fight includes 18 "issues" which I will be reporting to GnuTLS developers soon; until those are resolved, the build I did is anything but an automatic thing. And I don't see how anyone else's build can be fully automated, unless the "issues" I bumped into are due to my own misunderstandings. In any case, my experience indicates that having a steady feed of regular updates of Windows builds of any non-trivial package can never be based on a single individual, no matter if his/her name is Eli, Nicos, or something else. People invest in this some time for as long as they have it or are interested, and then go away to pursue other interests or go on with their lives. You cannot build a reliable infrastructure on something that is not part of your project. Bottom line, I feel that letting users download and unzip DLLs is by far more practical for this purpose than what you suggest. It also has the advantage of already working.