From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26175 invoked by alias); 27 Oct 2011 20:07:25 -0000 Received: (qmail 26167 invoked by uid 22791); 27 Oct 2011 20:07:23 -0000 X-SWARE-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from out5.smtp.messagingengine.com (HELO out5.smtp.messagingengine.com) (66.111.4.29) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 27 Oct 2011 20:07:06 +0000 Received: from compute5.internal (compute5.nyi.mail.srv.osa [10.202.2.45]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 7F9AA20743 for ; Thu, 27 Oct 2011 16:07:05 -0400 (EDT) Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161]) by compute5.internal (MEProxy); Thu, 27 Oct 2011 16:07:05 -0400 Received: from [158.147.67.90] (158-147-67-90.harris.com [158.147.67.90]) by mail.messagingengine.com (Postfix) with ESMTPSA id 369A64833EF; Thu, 27 Oct 2011 16:07:05 -0400 (EDT) Message-ID: <4EA9B9E8.2030106@cwilson.fastmail.fm> Date: Thu, 27 Oct 2011 20:07:00 -0000 From: Charles Wilson Reply-To: Charles Wilson User-Agent: Mozilla/5.0 (Windows NT 5.2; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: cygwin@cygwin.com Subject: Re: Request update of TCL and expect packages References: <4EA86D31.5040206@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com X-SW-Source: 2011-10/txt/msg00565.txt.bz2 Please don't top-post. Reformatted below. On 10/27/2011 2:43 PM, Craig Miller wrote: > On Thu, Oct 27, 2011 at 11:37 AM, Dave wrote: >> I hope this isn't a dumb question... No, it's not a dumb question, but... >> Since TCL is designed to support multiple versions installed simultaneously, >> and there are already quite a few Cygwin packages that have dependencies on >> various versions of libraries, why not have a new TCL85 and EXPECT545 >> packages? Just leave all the other packages that depend on TCL8.4 alone? >> Perhaps Mr. Miller would volunteer to be the Cygwin package owner for these >> two new packages. Even if he were to abandon support, the situation would be >> better since we'd have >much< more modern versions of TCL/EXPECT for Cygwin. > > This sounds like a not unreasonable solution (having 2 sets of > tcl/expect packages). I can see that there might be a confusion factor > for newbies, so it would be good to get a few more opinions. Unfortunately, it's not really possible *right now*. Maybe, going forward, future versions of (e.g.) tcl8.6 could co-exist with the new 8.5 ones [1]. The problem IIRC is that until recent versions (which cygwin-tcltk is /not/), all versions of tcl used the same directory to store their addons. This means that (old) tcl would "see" and attempt to load/use the addons built and configured for (new) tcl. Ditto tk. Also, as detailed below [1], even then there are other issues with the dev files that still aren't fixed in upstream. :-( To make this work (again IIRC) you'd have to backport the relevant changes to cygwin's ancient tcltk packages, and then rebuild them, as well as rebuilding the associated addons so that they go into a non-conflicting location. That's a lot of effort. I gave it a shot several years back -- it kinda sorta worked, but not very well. Now, if the argument is "but I want a GDI version of tk, and you guys are switching to X!" (rather than "I simply LOVE ancient and obsolete technology! tcltk-20080420-1/8.4 forever!!eleventy!11!!") -- then... One alternative would be to build the entire (new) stack with an alternate prefix (such as /opt/tk-gdi/), with the appropriate patches so that tk is pure cygwin + GDI (rather than win32ish + GDI, as the current, ancient, versions are). I doubt this would have much chance to be added to the distro, but you can always set up a repo to share this effort, like Yaakov/cygwin-ports has done. [1] But Yaakov's package naming choice won't allow that to work "smoothly". Basically, the various elements (tcl, tk, itck, etc) would each need to be "broken up" into subpackages. Further, /some/ of those subpackages would need to have "versioned" names -- like we do for so-called "dll" packages -- while other subpackages would need, e.g., alternatives support for conflicting files (e.g. who provides the unversioned "wish.exe" or "tclsh.exe"?). However, lest this be taken as a criticism of Yaakov's packages, the problem is tcl/tk/etc aren't really *set up* for this sort of thing. You'd need additional patches so that the "build" headers (currently in /usr/include/*.h) could be moved to (say, /usr/include/tcl8.5/*.h) -- and tcl itself patched so that add-on builds could "find" them there. It's really a big mess. I posted an attempt at this several years ago, but it requires a lot of patching and fiddling -- and really should be handled by upstream. It's not something distributors -- like Fedora or cygwin -- should take on themselves. Until upstream gets its act together for co-installs... -- Chuck -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple