Mailing-List: contact cygwin-apps-help AT sourceware DOT cygnus DOT com; run by ezmlm
Sender: cygwin-apps-owner AT sourceware DOT cygnus DOT com
Message-ID: <3BA63755.9040406@ece.gatech.edu>
Date: Mon, 17 Sep 2001 13:48:05 -0400
From: Charles Wilson <cwilson AT ece DOT gatech DOT edu>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010713
MIME-Version: 1.0
To: Corinna Vinschen <cygwin-apps AT cygwin DOT com>
Subject: Re: [RFD] ncurses update
References: <3BA3A5F4 DOT 8010100 AT ece DOT gatech DOT edu> <20010917182915 DOT C10081 AT cygbert DOT vinschen DOT de>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Corinna Vinschen wrote:

> On Sat, Sep 15, 2001 at 03:03:16PM -0400, Charles Wilson wrote:
> 
>>This is an ABI change, requiring the DLL number to be bumped, and apps 
>>to be recompiled. (e.g. we now have cygncurses6.dll, etc)
>>
> 
> Somehow I don't like the `6' here for a ncurses-5.2 version but
> if we can't avoid that...


Well, remember that library version != package version, esp. according 
to the libtool guys.  It's only a misunderstanding of this 
non-relationship, coupled with a misguided attempt by package 
maintainers to synchronize their library version number with the package 
major-version number, that causes these confusions.

I point the finger here at myself, as well as the ncurses maintainer in 
this particular case.  (ncurses aclocal.m4 explicitly sets 
"cf_cv_abi_version" to NCURSES_MAJOR.  Blech.  Perhaps, *perhaps*, the 
API version number could be the same as NCURSES_MAJOR.  But not the ABI 
version number -- the upstream maintainer has no *direct* control over 
the ABI; binaries are the responsibility of the distribution provider...)

In the past (before I understood the distinction) I used package version 
numbers as the dll version numbers, too.  But now I've learned better, 
and refuse to fall prey to that misconception again.  Of course, that 
means that if the cygwin-specific ABI changes more frequently than the 
official package's ABI/API (due to changes in build proceedure, or 
whatever) -- then "our" DLL version number will not remain in sync with 
the "official" sharedlib version number.  This will, perhaps, lead to 
confusion later -- especially if the official maintiner (GNU people? 
FSF?) attempt to ALSO keep their package-major version number in sync 
with their shlib version number (thus, our cygwin specific DLL version 
number will ALSO be out of sync with the package-major version number) 
However, I think this is, unfortunately, unavoidable.

Note that Red Hat bases its RPM names on the shlib version number, not 
the package major version (which it DOES version them; RH doesn't often 
do so -- Mandrake does it more often).
e.g. RH:  libole2-0.1.7-2-i386..
      MDK: libcurl1-7.6.1-2mdk    libmirrordirz1-0.10.49-2mdk
(There are other library packages in both distros that (a) are 
"versioned" and (b) the package name version == package major version -- 
usually because the upstream maintainers have made a misguided attempt 
to synchronize the two.  libncurses5 is like this)

We made the same sacrifice w.r.t. cygreadline5 (from readline-4.2).

 
>>What do you think about the following?
>>---------------------------------------
>>
>>a) the --enable-auto-import change to ncurses (and its related 'bump the 
>>DLL number requirement)
>>
> 
> If it works, it's ok with me.


Seems to work fine here.  I'd like wider testing -- but the setup/[test] 
designation problem prevents me from putting my new packages on the 
mirrors as a test release (see original message)


>>b) the new libncurses5 package?  (should I just put the old DLLs inside 
>>ncurses-5.2-6 package?  should the new DLL's themselves be split from 
>>the ncurses package and put in libncurses6 package?)  What about the 
>>source code naming difference (libncurses5 != ncurses)?
>>
> 
> Splitting is ok but what about just naming the file `ncurses5-5.2-1'?
> The package would be nearer to the other ncurses package in setup's
> package dialog.


No objections here -- but Red Hat doesn't do it that way (nor does any 
other RPM-based distro).  Don't we want to be like Red Hat?


>>c) splitting the terminfo package (and forking the source code)  For: 
>>allows me to update the terminfo database more frequently and easier. 
>>Against: forking is bad.
>>
> 
> Forking is good here.


Note that Red Hat follows your previous argument, here.  They name the 
"terminfo" package as "ncurses" (plus a few executables).  most of what 
I have in "my" new ncurses package, Red Hat calls "ncurses-devel".  And 
of course, Red Hat has both "libncurses4" (VERY old, RH5.0 days) and 
"libncurses5"

Thus, my version ---- Cygwinized RH version
   ncurses          =>  ncurses-devel + libncurses6
   libncurses5      =>  libncurses5
   terminfo        =>  ncurses
(with migration of a few files between these equivalencies)


> Q: If I have installed the new ncurses package and I want to
> rebuild e.g. tcsh, do I have to change my Makefile?  Do I have
> to change anything?


Nope.  It *should* "just work".

--Chuck