Mailing-List: contact cygwin-apps-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-apps-owner AT cygwin DOT com
List-Subscribe: <mailto:cygwin-apps-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-apps/>
List-Post: <mailto:cygwin-apps AT cygwin DOT com>
List-Help: <mailto:cygwin-apps-help AT cygwin DOT com>, <http://sources.redhat.com/lists.html#faqs>
Delivered-To: mailing list cygwin-apps AT cygwin DOT com
Message-ID: <3C1D5515.3030405@ece.gatech.edu>
Date: Sun, 16 Dec 2001 21:14:45 -0500
From: Charles Wilson <cwilson AT ece DOT gatech DOT edu>
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: Robert Collins <robert DOT collins AT itdomain DOT com DOT au>
CC: cygwin-apps AT cygwin DOT com
Subject: Re: Restructuring gettext
References: <3C18EBA9 DOT 9030102 AT ece DOT gatech DOT edu> <20011213215926 DOT GA20163 AT redhat DOT com> <3C192A8F DOT 168CF40F AT ece DOT gatech DOT edu> <103a01c18603$84a934b0$0200a8c0 AT lifelesswks>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)

Robert Collins wrote:


>>Any other comments about the restructuring itself?  Unfortunately, I
>>
> see
> 
>>this sort of thing being necessary for a lot of packages that provide
>>DLL's: and not just because "we" change the way we build 'em.
>>
> Sometimes
> 
>>the upstream folks change the API -- like readline.  Hopefully these
>>disruptions can be "spaced out" so they don't all hit at once...
>>
> 
> If the API changes, bump the .dll number and the package number. 


Of course.  But we're dealing with two different issues: the current 
(monolithic) packaging of certain libraries, coupled with the need for 
multiple versions of shared libs to coexist on the same system.

> One
> thing I've seen debian (who face this issue much more often than RPM
> based distro's due to the decentralised upload regime) do is have
> libncurses0, libncurses1,libncurses2 etc, which is NOT related to the
> version of ncurses, but to the major version number libtool generates


Absolutely.  That was my plan -- but step #1 of that plan is to split 
out the shared lib from the monolithic package (which can only have ONE 
instance on any given system).

Since other than Corinna's recent dllizations and bzip2 (and cygwin 
itself, of course), most of the dll-containing packages are mine.  I 
*could* embark on a grand quest of "split out the DLL into a separate 
libfooX package" without ANY other substantive changes -- "in 
preparation for DLL updates later".  But why?  I prefer only to disrupt 
when and as necessary...

And even though cygintl-1.dll SEEMS to be backward compatible with 
cygintl.dll, the switchover to libtool-controlled building (and DLL 
naming) requires this splitout for the gettext package)


> (and any package that changes the API without updating the libtool
> compatability triplet (which may or may not bump the major version
> number) should get shot at by rednecks).


Sure -- if libtool is involved.  Sometimes it isn't and I have to track 
API compatibility myself...but I'm prepared for that.

--Chuck