Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Message-ID: <3CB4730A.7090709@ece.gatech.edu> Date: Wed, 10 Apr 2002 13:14:50 -0400 From: Charles Wilson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: Randall R Schulz CC: cygwin AT cygwin DOT com Subject: Re: [ANNOUNCEMENT] Updated: bzip2-1.0.2-1 References: <5 DOT 1 DOT 0 DOT 14 DOT 2 DOT 20020410091725 DOT 027f32d8 AT pop3 DOT cris DOT com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Randall R Schulz wrote: > Say what? > > This package showed up at Mirrors.rcn.net yesterday, Hmm...I didn't even upload the files until just after midnight EDT Wednesday morning (and announced it simultaneously). That's some pretty fast mirroring...see way below. > and I downloaded > and installed it without incident or complaint using the > previous-generation Setup.exe (2.125.2.10). Right -- previous generation setup didn't support dependencies. So, you didn't install the 'libbz2_0' package, on which bzip2 now depends (sortof, see below). It's actually the libbz2_0 package that old setup.exe's will be confused by. Since you didn't even try to install it (no automatic dependencies), then you didn't have any problems. Until you try to run a program that needs cygbz21.0.dll. (below): However, the actual executables in the bzip2 package were linked STATICALLY for precisely this reason -- so that folks like you wouldn't have problems. In fact, the "dependency" of the bzip2 package on the libbz2_0 package is fiction; nothing in the bzip2 package needs the dll -- except for the import library. And any programs that individual users may have compiled PREVIOUSLY that they linked dynamically against the OLD bzip2 package's cygbz21.0.dll. Trust me: all of these gyrations are necessary, including splitting bzip2-1.0.1-6 into two separate packages (bzip2-1.0.2-1 and libbz2_0-1.0.2-1), so that I can migrate bzip2 to the auto-import build style. That will greatly simplify things...but this step had to happen first. Unfortunately, I ran into some problems with the package name, setup.exe, and the fact the "libbz2" -- the official library name of the bzip2 package -- ends in a numeral. On cygwin, I've been naming the "DLL-only" packages with a traling numeral that indicates the DLL major version (this allows peaceful coexistence and backward compatibility: see libreadline4/libreadline5, libncurses5/libncurses6, etc.) libbz20-1.0.2-1 ? looks like twenty, to me libbz2-0-1.0.2-1 ? oops, setup will parse the '0' as the source version, and 1.0.2 as the release version, and the -1 gets thrown away. So, we settled on libbz2_0 -- but old setup.exe's treated '_' and '-' the same. New setup.exe's do NOT use '_' as a parsing separator. Therefore: libbz2_0-1.0.2-1 ==> packagename=libbz2_0 version=1.0.2 release=1 which is what I needed. However, old setup.exe's will be confused... > By the way, if this sort of dire warning is associated with a new > release, shouldn't the announcement go out before the package itself? way below: It did. However, the gateway between cygwin-announce@ and cygwin@ has been broken since Sunday. Chris is working on it. But, when I noticed that it wasn't working, I resent the announcement directly to cygwin@ by hand; unfortunately I didn't do that manual intervention last night, but this noon. Sorry. --Chuck -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/