Mailing-List: contact cygwin-apps-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-apps-owner AT cygwin DOT com
Mail-Followup-To: cygwin-apps AT cygwin DOT com
Message-ID: <3CA4D9E3.3010008@ece.gatech.edu>
Date: Fri, 29 Mar 2002 16:17:23 -0500
From: Charles Wilson <cwilson AT ece DOT gatech DOT edu>
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2
MIME-Version: 1.0
To: cygwin-apps AT cygwin DOT com
Subject: Re: How to create a ksh93 package...
References: <20020328221439 DOT GJ16757 AT redhat DOT com> <00e001c1d73a$43392ca0$f20114d5 AT muffin> <20020329175705 DOT GE2505 AT redhat DOT com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Christopher Faylor wrote:


> However, anything other than ksh needs to go through the standard
> package acceptance: http://cygwin.com/setup.html .


That sounds reasonable to this observer.


> I still have serious supportability concerns wrt including other
> programs with similar names as part of the cygwin package.


Of the four packages I recommended, this affects only one of them.  ksh, 
ksh-accel, and ksh-devel exist only to support ksh and user-custom progs 
that want to include ksh functionality internally (-devel).  And, of 
course, ksh-accel is not necessary for regular (slow) operation of ksh 
itself.


> It may be convenient for *you* to have these available.  It may not
> be convenient for *me* and anyone else who is volunteering to support
> cygwin.  If you lose interest or move on, then I'll be the one asking
> "Which version of 'ls' are you running?" and attempting to figure out
> what's wrong with the "ast" version of things.


Hmm...with the multi-site capability of setup, you *could* have ksh-ast 
live at a separate location; ditto ksh-accel and ksh-devel.  (But ksh 
itself is a part of cygwin's dist).  Then, the README file in ksh 
package (/usr/doc/ksh/ksh-x.y.z.README) could give instructions for how 
to use setup to get the other packages...as could the announcement on 
the main cygwin web page ("for added ksh goodies, add http://foo to your 
setup.exe download list").

And if the "separate site" was actually 
http://cygwin-mirror-here/cygwin/external/ast/* ...

But that's a whole lot of bother (compared to just adding the "extra" 
packages to the *main* cygwin dist), and there are two problems with it:

1) making it too easy to add the "extra ksh stuff" means that lots of 
folks will do it (leading to AST vs. GNU name conflicts and 
supportability problems, as you fear)

2) making it too hard to add the "extra ksh stuff" means that folks who 
want ksh will be upset with our version: "it doesn't act like ksh on FOO 
platform because I'm missing XXXXXX" (when the whole point of ast/ksh is 
identical operation on EVERY platform).

I don't know where that balance should be drawn.  I lean toward freedom 
(provide 'em all) but then, this can ONLY lead to increased mailing list 
petulance...I tire of answering questions...


> Maybe your interaction in the cygwin mailing list will increase once
> you've gotten a package or two released but, so far, it seems like you
> disappear for a month or two between discussions.  If that is an
> expected pattern, then I don't think I want to invest in releasing
> something that will upset the fragile sensibilities of the cygwin
> mailing list community.


In Karsten's defense, I believe he has been more involved with the AST 
folks, trying to get ksh to work nicely on cygwin -- why bother "the 
cygwin list" with his problems; he's solving them himself.  (He even 
figured out the DLL naming for cygwin dlls all by himself -- that 
indicates an archive search happened at some point...)


> I think I'd be more comfortable with keeping alternate tools out
> of the distribution.  We can easily advertise them on the cygwin web
> page and, if requested, I'll even make space available on the ftp
> server for them.

See above: too easy vs. too hard discussion.

--Chuck