This is the mail archive of the cygwin-apps@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Restructuring gettext


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]