How to create a ksh93 package...

Charles Wilson cwilson@ece.gatech.edu
Wed Mar 27 16:29:00 GMT 2002


 >> 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



More information about the Cygwin-apps mailing list