Mail Archives: cygwin-apps/2001/09/17/13:48:14
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
- Raw text -