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
