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: Wed, 04 Jan 2012 23:23:47 +0200 Message-ID: <83k457p3fg.fsf@gnu.org> References: <87ipktag2e.fsf@lifelogs.com> <87fwfxtxuz.fsf@wanadoo.es> <87aa64ubg9.fsf@wanadoo.es> <83boqkr9bp.fsf@gnu.org> <874nwcu17i.fsf@wanadoo.es> <834nwcr6un.fsf@gnu.org> <87vcosskhc.fsf@wanadoo.es> <831urgr2yr.fsf@gnu.org> <87r4zgsh2w.fsf@wanadoo.es> <87ipks3zbo.fsf@uwakimon.sk.tsukuba.ac.jp> <87boqk3q69.fsf@uwakimon.sk.tsukuba.ac.jp> <87aa634st8.fsf@uwakimon.sk.tsukuba.ac.jp> <87fwfvsgfv.fsf@wanadoo.es> <877h17scdo.fsf@wanadoo.es> <87hb0b77nr.fsf@lifelogs.com> <8739bvs27m.fsf@wanadoo.es> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE X-Trace: dough.gmane.org 1325712357 23427 80.91.229.12 (4 Jan 2012 21:25:57 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 4 Jan 2012 21:25:57 +0000 (UTC) Cc: emacs-devel@gnu.org To: =?utf-8?Q?=C3=93scar?= Fuentes Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jan 04 22:25:53 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 1RiYLH-0004ZH-Cr for ged-emacs-devel@m.gmane.org; Wed, 04 Jan 2012 22:25:51 +0100 Original-Received: from localhost ([::1]:60809 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RiYLG-0004sh-TG for ged-emacs-devel@m.gmane.org; Wed, 04 Jan 2012 16:25:50 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:48899) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RiYLD-0004sT-Lq for emacs-devel@gnu.org; Wed, 04 Jan 2012 16:25:48 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RiYLC-0004pO-Kf for emacs-devel@gnu.org; Wed, 04 Jan 2012 16:25:47 -0500 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:44566) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RiYLC-0004p9-Cp for emacs-devel@gnu.org; Wed, 04 Jan 2012 16:25:46 -0500 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0LXA00M00M3PIJ00@a-mtaout22.012.net.il> for emacs-devel@gnu.org; Wed, 04 Jan 2012 23:25:07 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([77.126.18.76]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LXA00GSQM5RIOX1@a-mtaout22.012.net.il>; Wed, 04 Jan 2012 23:25:04 +0200 (IST) In-reply-to: <8739bvs27m.fsf@wanadoo.es> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 (beta) X-Received-From: 80.179.55.172 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:147294 Archived-At: > From: =C3=93scar Fuentes > Date: Wed, 04 Jan 2012 20:21:49 +0100 >=20 > This is a common scenario on MS Windows: multiple providers of bina= ry > packages, multiple installers with different install policies even = for > the same installer, lots of directories on PATH (each application l= ives > on its own directory and often wants to be listed on PATH), varying > policies about where a non-privileged user is allowed to put binari= es, > multiple incompatible binary macropackages that provides the same > executables and libraries with the same names (Cygwin, MSYS, GnuWin= 32 > and what-not), a lack of culture of system administration, a growin= g > tendency to rely on self-updating packages... and the list goes on. >=20 > If a user is informed about the need to fix GnuTLS (through the loc= al > newspaper, I guess) his first reaction would be "GnuWhat? Is it on = my > machine?" Next, as every desktop computer user would do, he perform= s a > full HD file search for the library ("and BTW, how is it named, > exactly?") After locating the instance (or multiple instances) he n= eeds > to figure out the correct procedure to update it ("Was this install= ed > along something else? Has this be put here by an installer of some = sort? > Does that installer offer an update method? What depends on this dl= l? > What's the installed version, and what's the compatible update? Is = it > available somewhere? If I use this newer version which I found with= a > Google search, can something break apart?") >=20 > Sure, for us it all looks very easy, but I suffered DLL hell a few = times > and it is very frustrating. Can't imagine how can it be for a novic= e or > a less computer-savvy user. You are describing a situation that existed on Windows 9X, it no longer exists on modern machines. DLLs are either versioned in their names or use the SxS mechanism. Take the GnuTLS example: the previous DLL of version 2.x was named libgnutls-26.dll, while the new 3.x one is libgnutls-28.dll. Use you= r friendly depends.exe program, and you will see that programs that depend on one of them (were linked with its import library) will refuse to load the other. The same is true of libintl, libiconv, and all the other libraries many Windows ports of GNU software need. Poof! the problem doesn't exist. Please stop spreading this FUD, you are tripping people like Ted who don't know better into wrong conclusions based on what hurt you (and me) several years ago. THERE'S NO SUCH PROBLEM ANYMORE! > For a Windows binary package to be robust, it must be as self-conta= ined > as possible. True, but irrelevant.