Okay, after two days we've gotten one reply, from Kevin Roth (a nonmaintainer, I think). But nothing else.
Are any *current* maintainers going to help us decide here, or am I going to have to fly down under for a Robert-v-Chuck arm-wrestle match to settle this? See http://www.neuro.gatech.edu/users/cwilson/cygutils/packaging/ To restate the positions; mine: (#1) -src tarball contains cygwin/SOURCES/<pristine tarball, without renaming or repacking> cygwin/SOURCES/<patchfile> (possibly other stuff in cygwin/SOURCES/, if necessary) cygwin/SPECS/<build script or makefile> newly generated tarballs placed in cygwin/RPMS newly generated src tarballs placed in cygwin/SRPMS since setup will unpack the cygwin-distributed -src tarball under /usr/src, all this stuff therefore happens in /usr/source/cygwin/*/ the build script, when run, unpacks the pristine tarball and renames the unpacked directory to be "pkg-ver-rel" instead of whatever the upstream developers may have chosen for their source packages (mv tiff-v3.5.5/ tiff-3.5.5-2/). This way, we fit into "the cygwin way" but don't have to repack the "pristine" tarballs at all. (Alternatively, we don't *HAVE* to do this. We can just use whatever dirname the upstream folks put in their pristine tarball. It's all controlled by the script in SPECS/) Good points: more "RPM" like. Also, the build script is right there -- no need to unpack & patch first; the build script will do that for you. Therefore, this is more automated. Bad points: assumes a cygwin/*/ structure. (Not *necessarily* /usr/src/cygwin/*/ -- it could be ~/cygwin/*/) --------------------------------------------------- Robert's: (#3) -src tarball contains <pristine tarball, without renaming or repacking> <patch> since setup unpacks these under /usr/src, these files end up right there in /usr/src. newly generated tarballs are placed *right here* (in /usr/src) ditto newly generated -src tarballs Currently, one must manually unpack the pristine tarball, and apply the patch. (Later, perhaps setup can do this for us). Then, the build script is created inside the unpacked source directory. Good points: self contained. The build script need not assume anything about the "surrounding' directory structure. once the user unpacks and patches, <srctop>/CYGWIN-PATCHES/buildscript will do all the work, and generates the new tarballs in <srctop>/.. Bad points: User must manually unpack and patch (or setup must do it). IMO, having the build script inside the source tree is awkward. Also, there seems to be little provision for additional patches or archives if the "pristine" src archive + 1patch isn't enough to properly handle the port (cf. /usr/doc/Cygwin/ncurses-5.2.README) --------------------------------------------------- Worst of both worlds: (#2) -src tarball contains cygwin/SOURCES/<pristine tarball, repacked, renamed> renamed so that the tarball follows some agreed-upon standard name (foo-ver-origsrc.tar.bz2 ?) repacked so that it will unpack into an agreed-upon standard directory (foo-ver-rel/ ? foo-ver/ ?) instead of whatever random thing the upstream folks picked (jpeg6b? tiff-v3.5.5? Ugh). apply the patch, and then the build script is created within the unpacked source directory. It is assumed that the user (or setup) will unpack the pristine source into cygwin/BUILD. That script will (eventually) generate the new tarball in cygwin/RPMS, and the new -src tarball in cygwin/SRPMS. good points: Closer to the RPMish structure. (?) Bad points: repacking, renaming the "pristine" tarball. Also, assumes a lot about *where* the end user will manually unpack -- unless setup does this for us. Also the single src archive + 1 patch only problem. --------------------------------------------------- --Chuck