Mailing-List: contact cygwin-apps-help AT cygwin DOT com; run by ezmlm Sender: cygwin-apps-owner AT cygwin DOT com List-Subscribe: List-Archive: List-Post: List-Help: , Mail-Followup-To: cygwin-apps AT cygwin DOT com Delivered-To: mailing list cygwin-apps AT cygwin DOT com Message-ID: <3CB31B22.9070404@ece.gatech.edu> Date: Tue, 09 Apr 2002 12:47:30 -0400 From: Charles Wilson User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: cygwin-apps AT cygwin DOT com Subject: Re: Now that the new setup is here... References: <3C9F9092 DOT 2030700 AT ece DOT gatech DOT edu> <3CA6AB30 DOT 6060905 AT ece DOT gatech DOT edu> <3CAAA150 DOT 2090507 AT ece DOT gatech DOT edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Charles Wilson wrote: >>> 1) move gettext from the contrib directory to the latest directory -- >>> and see if anybody barfs. > > I did this. It's been many moons and many point releases (and a major > release) since the last time we moved a package directory (ncurses, I > think) from contrib to latest. Hopefully the changes in the internal > logic -- and the greater reliance on setup.ini -- mean that this will > cause little if any disruption. (Also, Robert asserts that it will > cause no damage). So, a test (in preparation for cgf's possible reorg?) > > Besides, we have a several 'latest' packages (bison, grep, sharutils, > texinfo, textutils, vim) that depend on libintl (gettext). The "policy" > was that 'latest' stuff should depend only on other 'latest' stuff -- > that was the rationale for moving ncurses, anyway. Okay, it's been a week -- and nobody seems to have noticed. That's promising. So, I'll go out on a limb here, and predict that cgf's massive reorg of the sourceware/cygwin dir structure won't upset setup (no pun intended). However, it may upset people who are anal about what setup does inside it's own "localdir" playground, and may lead to lots of duplication and unnecessary re-downloads -- which is bound to cause consternation. But those are social problems, not technical ones. >>> 2) update bzip2 to the latest release -- which involves the grand >>> library split thing (bzip2 -> bzip2 + libbz2_0). However, the name >>> "libbz2_0" is incompatible with the old setup, and even 'cygcheck -c' >>> gets confused prior to the cygwin-1.3.8 release. > > But I didn't do this. So, what's the opinion here? Should we cross the Rubicon? --Chuck