Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT sources DOT redhat DOT com Delivered-To: mailing list cygwin AT sources DOT redhat DOT com Date: Fri, 19 Jan 2001 14:25:39 -0500 From: Christopher Faylor To: cygwin AT cygwin DOT com Subject: Re: Problems with talk utility from inetutils Message-ID: <20010119142539.D7746@redhat.com> Reply-To: cygwin AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com References: <005501c080f0$6a94d8e0$e088f726 AT holstein-mobile DOT ASPECTDV DOT COM> <20010118145058 DOT D4318 AT cobold DOT vinschen DOT de> <3A674860 DOT 66F592F1 AT ece DOT gatech DOT edu> <20010118192459 DOT F1732 AT redhat DOT com> <20010119121544 DOT U4318 AT cobold DOT vinschen DOT de> <3A687310 DOT 15F9184E AT ece DOT gatech DOT edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.11i In-Reply-To: <3A687310.15F9184E@ece.gatech.edu>; from cwilson@ece.gatech.edu on Fri, Jan 19, 2001 at 12:02:08PM -0500 On Fri, Jan 19, 2001 at 12:02:08PM -0500, Charles S. Wilson wrote: >Corinna Vinschen wrote: > >> > >Just a question: since ncurses is a "contrib" item, should inetutils use >> > >it or should inetutils just compile against termcap? >> > >> > It should compile with termcap. That may be tricky if terminfo is >> > installed, though. >> >> It doesn't compile with termcap. It depends on curses. If curses >> (or ncurses) isn't available on a system, talk and talkd are not >> build. IMHO, the ncurses package should be moved from contrib to >> latest anyway. > >Ah. Well, this makes inetutils the first official, non-contrib package >to depend on ncurses. This sounds like a good policy to me: when a >'latest' package is built to depend on a 'contrib' package, move the >'contrib' package into 'latest'. > >However, I remember massive confusion when zlib was moved from 'latest' >to 'contrib'. Do you suppose that will recur in this instance, or was >that just an artifact of setup.exe's evolution? (e.g. setup was just >learning how to deal with multiple subdir paths...) I'm sure that everything will be just fine or, if not, people will figure everything out for themselves and do the right thing. cgf (the medication is finally kicking in) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) ;-) -- Want to unsubscribe from this list? Check out: http://cygwin.com/ml/#unsubscribe-simple