Mailing-List: contact cygwin-apps-help AT cygwin DOT com; run by ezmlm Sender: cygwin-apps-owner AT cygwin DOT com List-Subscribe: List-Archive: List-Post: List-Help: , 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 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> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit >> 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