Historical Cygwin Packaging
There are two previous ways of packaging source code for Cygwin packages.
Source packages are extracted underneath /usr/src (so your -src tarball should not include /usr/src). On extraction, the tar file should put the sources in a directory with the same name as the package tar ball minus the -src.tar.bz2 part:
- In your source package include the same foo-vendor-suffix.README as used in the binary package.
- Your source package already be patched with any necessary Cygwin specific changes. The user should be able to just ./configure; make; and go.
- Include a single file foo-vendor-release.patch in your source package, that when applied (in reverse: 'patch -R') will remove all the patches you've applied to the package, leaving it as the vendor distributes it. This file should extract as : /usr/src/foo-vendor-release.patch (that is, since setup extracts everything into /usr/src, the patch should be a "top level" member of the -src tarball.)
Optionally, this patch could also unpack inside the source tree:
However, that tends to complicate actually creating the patch itself. Unless one enjoys recursion, one must move the .patch file OUT of the source tree, regenerate the patch to incorporate any new changes, and then copy the new patch back into .../CYGWIN-PATCHES/. This option is documented because some existing packages do it this way, but it is not recommended for new packages. Make boffo-1.0-1.patch a top-level member of the -src tarball instead:
To create the patch file described above, you might run
diff -Nrup vendor-src-dir patched-src-dir > foo-vendor-release.patch
To apply the generated patch (in reverse; that is, to remove the Cygwin specific changes from the unpacked -src tarball) the user would run (from within the source tree)
patch -R -p1 < ../foo-vendor-release.patch
- In general, any Cygwin-specific "packaging" files -- such as cygwin-specific READMEs, a copy of the setup.hint file for your package, etc. -- should unpack within a /CYGWIN-PATCHES/ subdirectory in your sources. Naturally, applying the patch (in reverse, as described above) would remove these files from the source tree.
- So, returning to the boffo example, boffo-1.0-1-src.tar.bz2 would contain:
This method is sometimes referred to as the "g-b-s" method, after the filename of the generic-build-script template.
- In a packaging technique inspired by rpms and debs, you may create a -src tarball which simply contains:
- foo-vendor.tar.[gz|bz2]: The original source tarball, exactly as downloaded from the original vendor.
- foo-vendor-release.patch: the patch file as described in Method One, above.
- foo-vendor-release.sh: A build script that drives the entire unpacking, configuration, build, and packaging (binary and -src) process.
- You can adapt this generic readme file for script-driven -src packages.
- Here is an example build script which can be adapted for your package. By carefully modifying the details of this script, it can create the binary and -src packages for you, once you've finished porting your package. How? See the Initial packaging procedure below. But first, a few facts:
- The buildscript will autodetect the package name, vendor version, and release number from its own filename.
- When the buildscript is used to compile the package, all building occurs within a hidden subdirectory inside the source tree: boffo-1.0/.build/
- To create the binary package, the script redirects 'make install' into a hidden subdirectory boffo-1.0/.inst/, creating a faux tree boffo-1.0/.inst/usr/bin, etc. This faux tree is tar'ed up into the new binary package.
- To create the -src package, the script generates a patch file, and copies the original tarball, the patch, and the script into yet another hidden subdirectory boffo-1.0/.sinst/. The contents of this subdirectory are tar'ed up into the new -src package.
- Sometimes, you will find that a package cannot build outside of its source directory. In this case, the script must recreate the source tree within the .build subdirectory. The jbigkit -src package uses GNU shtool's mkshadow to do this.
- generic-build-script is not a one-size-fits-all solution. It must be customized for your package.
Initial packaging procedure, script-based