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
List-Subscribe: <mailto:cygwin-apps-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-apps/>
List-Post: <mailto:cygwin-apps AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-apps-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/lists.html#faqs>
Delivered-To: mailing list cygwin-apps AT sources DOT redhat DOT com
Message-ID: <3BA958FB.7060401@ece.gatech.edu>
Date: Wed, 19 Sep 2001 22:48:27 -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
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: ncurses announcement - trial run
References: <EA18B9FA0FE4194AA2B4CDB91F73C0EF08F1A3 AT itdomain002 DOT itdomain DOT net DOT au>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Robert Collins wrote:

> Should the man pages be in with the .dlls? Or at least the end user ones
> that refer to setting TERM etc?


I was just following the lead of the other distros RPMS. Besides, what 
you suggest would cause conflicts -- both libncurses5 and libncurses6 
would contains these man pages, leading to ordering problems with 
upgrades (Or, forcing me to update libncurses6 MERELY because 
libncurses7 is coming out -- update 6 so NOT include those man pages. 
But then you STILL have ordering problems.)

RedHat:
   ncurses
     so's and ld-conf-style so-links, utility programs,
     man(1) pages for utils, term(5), terminfo(5), term(7)
     terminfo database
   ncurses-devel
     static libs, developmen links for so's (e.g. import
     libs in windows parlance), sources for the test programs,
     man(3) pages
   ncurses4
     contains old so's.

Mandrake:
   libncurses5-....,rpm
     contains only the .so's and ld.conf-style so-links
     (but NOT the development links)
   ncurses-devel
     contains static libs, headers, the man(3) pages,
     sources for the test programs, development links for
     the shared libs
   ncurses
     contains the utility programs, and the man pages (for
     those programs only, term(5), terminfo(5), term(7))
     the terminfo database, and a few other docs

(NOTE that I was wrong earlier; Corinna suggested naming my libncursesX 
packages as ncursesX -- I replied that Red Hat didn't do that.  However, 
Red Hat *does* do that.  Mandrake uses the 'lib' nomenclature)

I have:
   libncurses6
     contains only the shared libraries
   ncurses
     contains everything in Red Hat's ncurses-devel and
     ncurses RPMS, minus the terminfo database
   terminfo
     contains the terminfo database
   libncurses5
     contains old shared libraries

> 
> Could the static library and header tarball be called ncurses-dev-5.2-6
> ? (I hope the reason is obvious :})


The way I have it, the ncurses package contains the devel stuff, but 
also the utility programs, generic documentation, and utility man(1) 
pages.  I thought about splitting my new ncurses into an 'ncurses' and 
'ncurses-devel' package -- but decided to let necessity be my guide -- 
only split if there is a *compelling* reason.
   terminfo -- fork for ease of update
   libncursesX -- necessity for back compatibility given setup.exe's
     capabilities.
   everything else goes in ncurses.

Basically, I don't *really* want to start a trend of splitting all the 
packages into oodles of itty bitty foo, foo-devel, foo-doc, foo-client, 
foo-server, packages.  Necessity drives me this far -- but I don't want 
to go further just for the hell of it.


> 
> I don't think the linktime requirement is a biggy. Some folk will
> complain "I updated and now my *** app won't link". Other will read the
> README :|. No way around it though - with one exception.
> 
> We could release the cygwin binutils with --auto-import on by default.
> (Without propogating that change upstream).
> 

That's up to Chris.  Having just pestered him to release a new version 
with Ralf's fix, I'd prefer to wait before (a) bugging him again (b) 
slamming the mirrors with Yet Another Update.  Besides, there's a few 
more items on the TODO list for binutils; it'd be nice to push some of 
that thru before the next binutils rev.

--Chuck