Mail Archives: cygwin-apps/2002/03/29/16:19:47
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
> 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
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.
- Raw text -