delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin-apps/2002/03/27/19:29:59

Mailing-List: contact cygwin-apps-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-apps-owner AT cygwin DOT com
List-Subscribe: <mailto:cygwin-apps-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-apps/>
List-Post: <mailto:cygwin-apps AT cygwin DOT com>
List-Help: <mailto:cygwin-apps-help AT cygwin DOT com>, <http://sources.redhat.com/lists.html#faqs>
Mail-Followup-To: cygwin-apps AT cygwin DOT com
Delivered-To: mailing list cygwin-apps AT cygwin DOT com
Message-ID: <3CA25F67.80608@ece.gatech.edu>
Date: Wed, 27 Mar 2002 19:10:15 -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
X-Accept-Language: en-us
MIME-Version: 1.0
To: cygwin-apps AT cygwin DOT com
Subject: Re: How to create a ksh93 package...
References: <00c301c1d5e8$038b6300$f20114d5 AT muffin> <20020328000656 DOT GC2331 AT redhat DOT com>

 >> part shall change with minor updates, so I think "ksh93m+-1" would
 >>  be the correct name for a standalone Cygwin ksh93 package. Is
 >> this OK with you?
 >>
 >
 > I think so but I'll let the collective wisdom of cygwin-apps decide.

Sounds okay to me.

 >> I have to think about how to name the other packages and where to
 >> put the actual binaries (AT&T have their own implementations of
 >> all the common UNIX utilities but I think those shouldn't go into
 >>  /bin by default because they would be overwriting Cygwin
 >> standard tools).
 >>
 >
 > Do we really need to install other UNIX-like utilities?   That will be
 >  very confusing for users, I think.  Can't ksh just use the existing 
utilties?


Remember ksh has that in-process execution thing, where certain commands
are replaced by internally loadable modules...the stuff Robert was
talking about two weeks ago.

I suggest that the ksh-specific binaries should just go into
/usr/bin/ksh/, and folks who want to get the speedup of using ksh's
inprocess execution should just insure that /usr/bin/ksh/ is in the
front of their path.

Naturally, ksh can use the existing utilities, but you'll suffer a slowdown.

Did I get that right, Karsten?


 >>Package sources:
 >>AT&T don't use the GNU autotools and thus their source packages look
 >>quite different than most of the Cygwin packages and require _very_
 >>different actions to be taken to rebuild.
 >>
 >
 > That's no big deal.  Not everything in the cygwin release uses autoconf.
 >
 >
 >>Would it be OK to create a dummy -src package that just contains a text
 >>file (maye be with a suspicious name) which refers to the AT&T software
 >>download site?


Absolutely not.  We must distribute the sources OURSELVES in order to
comply with our own cygwin GPL license!

If you take a look at ncftp-3.1.2-1-src.tar.bz2, you'll see that it 
contains a patch,
 >
 > My preference would be for complete source but if this doesn't violate
 > an AT&T license agreement, then...  I'll let the people here weigh in
 > with an opinion.
 >
 > Could you post setup.hint files for your proposed package(s)?  Use the
 > instructions at the URL you mentioned and, if possible, scan the 
cygwin-apps
 > archives for comments on previous submissions to see what people have
 > suggested or objected to in the past.
 >
 > Thanks,
 > cgf
 >


 > > utilties?


Remember ksh has that in-process execution thing, where certain commands
are replaced by internally loadable modules...the stuff Robert was
talking about two weeks ago.

I suggest that the ksh-specific binaries should just go into
/usr/bin/ksh/, and folks who want to get the speedup of using ksh's
inprocess execution should just insure that /usr/bin/ksh/ is in the
front of their path.

Naturally, ksh can use the existing utilities, but you'll suffer a slowdown.

Did I get that right, Karsten?


 >> Package sources: AT&T don't use the GNU autotools and thus their
 >> source packages look quite different than most of the Cygwin
 >> packages and require _very_ different actions to be taken to
 >> rebuild.
 >>
 >
 > That's no big deal.  Not everything in the cygwin release uses
 > autoconf.
 >
 >
 >> Would it be OK to create a dummy -src package that just contains a
 >>  text file (maye be with a suspicious name) which refers to the
 >> AT&T software download site?

Absolutely not.  We must distribute the sources OURSELVES in order to
comply with our own cygwin GPL license!

If you take a look at ncftp-3.1.2-1-src.tar.bz2, you'll see that it 
contains a patch, the original source tarball, and a build script.  You 
can include a build script to unpack the original source tarball, patch 
it, do whatever is necessary to build it (even if it doesn't involve 
running "./configure")...

Feel free to adapt any of the build scripts you find in "my" packages if 
they are of any use to you.

 > My preference would be for complete source but if this doesn't
 > violate an AT&T license agreement, then...  I'll let the people
 > here weigh in with an opinion.

As I said above, not providing the sources to a cygwin-linked executable 
violates OUR license, regardless of whether it is allowed under THEIR 
license.

--Chuck

- Raw text -


  webmaster     delorie software   privacy  
  Copyright 2019   by DJ Delorie     Updated Jul 2019