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: <3CC380DB.2000100@ece.gatech.edu> Date: Sun, 21 Apr 2002 23:17:47 -0400 From: Charles Wilson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: Robert Collins CC: cygwin-apps AT cygwin DOT com Subject: Re: strange source packaging? References: <3CC26486 DOT 3000705 AT ece DOT gatech DOT edu> <001f01c1e905$efa327c0$0200a8c0 AT lifelesswks> Content-Type: multipart/mixed; boundary="------------060606070607080906080306" This is a multi-part message in MIME format. --------------060606070607080906080306 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Robert Collins wrote: > All the content changes look great however. If you can clean up the > space to tab conversion, I'm happy for this to go in. However as it's a > change to the standard... > > Any objections from any contributor? Okay, I've made the corrections you mentioned. I had "smart tabs" on earlier. Oops. The newly modified setup is here: http://www.neuro.gatech.edu/users/cwilson/cygutils/testing/setup.html --Chuck --------------060606070607080906080306 Content-Type: text/plain; name="setup.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="setup.patch" --- setup-old.html Sun Apr 21 22:45:52 2002 +++ setup.html Sun Apr 21 22:57:14 2002 @@ -22,7 +22,7 @@ - + @@ -94,11 +94,11 @@

Package file naming

Package naming scheme: use the vendor's version plus a suffix for +

Package naming scheme: use the vendor's version plus a release suffix for ports of existing packages (i.e. bash 2.04 becomes 2.04-1, 2.04-2, etc, until bash 2.05 is ported, which would be 2.05-1, etc). Some packages also use a YYMMDD format for their versions, e.g. binutils-20010901-1.tar.bz2. -The first release of a package should have a -1 suffix.

+The first release of a package should have a -1 release suffix.

A complete package currently consists of three files:

a setup.hint file

Binary tar files are named "package-version.tar.bz2". They generally +

Binary tar files are named "package-version-release.tar.bz2". They generally contain the executable files that will be installed on a user's system plus any auxilliary files needed by the package. See the making packages section below for more details on how to generate a binary tar file.

Source tar files are named "package-version-src.tar.bz2". Source tar files +

Source tar files are named "package-version-release-src.tar.bz2". Source tar files should contain the source files needed to rebuild the package. While installing these files is optional under setup.exe, the inclusion of a source tar file is part of the totality that makes up a cygwin package and so, these files are not optional. See the making packages section below for more +href="#srcpackage_contents"> making packages section below for more details on the contents of a -src tar file..

The setup.hint file is discussed below. @@ -126,22 +126,31 @@

Automatic setup.ini generation on sources.redhat.com

A script runs on sources.redhat.com which collects information from -(currently) the latest and contrib directories in the +(currently) the release directory in the ftp download area. Information from subdirectories of these directories is parsed to automatically generate the default setup.ini file which is used by the cygwin setup.exe program for installation control. If you are responsible for maintaining a cygwin package, it is important that you understand how this process works.

Packages are grouped by directory under latest or -contrib. The directory name is typically the same as the -package name. For example, the boffo package will live in the -boffo subdirectory. Exceptions to this rule are historical. -All new packages will follow the rule of package name == directory name. +

Packages are grouped by directory under release. The directory +name is the same as the package name. For example, the boffo package +will live in the boffo subdirectory. Exceptions to this rule are +historical. All new packages will follow the rule of package name == +directory name. However, for closely related groups of packages, it is acceptable +to use a heirarchical tree under release/: +


+  release/
+  release/boffo/
+  release/boffo/<boffo files>
+  release/boffo/boffo-devel/
+  release/boffo/boffo-devel/<boffo-devel file>
+

Each directory contains source and binary tar files which have been been compressed using bzip2. The required format of these filenames is: package-version[-src].tar.bz2 . +href="#naming">format of these filenames is: +package-version-release[-src].tar.bz2 . The contents of these files is discussed below. @@ -150,10 +159,13 @@

The version number must start with a digit and must adhere to the rules in package file naming above. Higher -version numbers are used for the current version of a package; the -previous stable version (if any) is used for the previous version -(however see setup.hint for exceptions to -this rule).

+version (and release) numbers are used for the current version of a +package; the previous stable version (if any) is used for the +previous version (however see setup.hint for +exceptions to this rule). Lexically, when two packages have identical vendor +version numbers, the one with the higher release number is considered +newer. Also, given two packages, the one with the higher vendor version +number is always considered newer, regardless of the release number.

The -src component of the filename is added to files which contain source code.

@@ -162,7 +174,7 @@ tar file, the "source" tar file, and the "setup.hint" file, e.g.:

-bash$ ls contrib/boffo
+bash$ ls release/boffo
 boffo-1.0-1.tar.bz2  boffo-1.0-1-src.tar.bz2  setup.hint

@@ -228,8 +240,8 @@ ordering. So, e.g., if you had previously released boffo-0.9-1 and now have a new boffo-1.0-1, the version numbering is obvious and there is no need to use curr or prev. It -is obvious that boffo-1.0-1 is newer than boffo-0.9-1 and the setup.ini -generator will do the right thing in this case.

+is obvious that boffo-1.0-1 is newer than boffo-0.9-1 and +the setup.ini generator will do the right thing in this case.

However, if you had discovered a serious error in the boffo-1.0 release, and then decided that you want to drop back to boffo-0.9-1, you @@ -297,13 +309,13 @@ description, e.g., this is incorrect:

-sdesc:	"boffo: A whackamole simulation in ASCII art"
+sdesc:      "boffo: A whackamole simulation in ASCII art"

This is correct:

-sdesc:	"A whackamole simulation in ASCII art"
+sdesc:      "A whackamole simulation in ASCII art"

Quote text that takes up several lines e.g.:

@@ -388,7 +400,7 @@

Multiple packages are separated by spaces. Do not enclose multiple package names within quotation marks.

Here's an example of a complete contrib/current/boffo/setup.hint:

Here's an example of a complete release/boffo/setup.hint:

 
     category: Games Text
@@ -428,7 +440,7 @@
 
 setup-version: number
 
-This line follows the setup-timestamp in all setupl.ini files.  It
+This line follows the setup-timestamp in all setup.ini files.  It
 indicates the version number of the setup.exe for which this setup.ini
 was generated.
 
@@ -495,22 +507,22 @@
 sdesc: Cygwin Runtime
 ldesc: A Posix runtime emulator for Windows platforms
 version: 1.1.4
-install: latest/cygwin/cygwin-1.1.4.tar.bz2 1234567
-source: latest/cygwin/cygwin-1.1.4.tar.bz2 1341245
+install: release/cygwin/cygwin-1.1.4.tar.bz2 1234567
+source: release/cygwin/cygwin-1.1.4.tar.bz2 1341245
 [prev]
 version: 1.1.3
-install: latest/cygwin/cygwin-1.1.3.tar.bz2 1234580
-source: latest/cygwin/cygwin-1.1.3.tar.bz2 1341123
+install: release/cygwin/cygwin-1.1.3.tar.bz2 1234580
+source: release/cygwin/cygwin-1.1.3.tar.bz2 1341123
 
 @ bash
 [test]
 version: 20000901
-install: latest/bash/bash-20000901.tar.bz2 276403
-source:  latest/bash/bash-20000901-src.tar.bz2 1892899
+install: release/bash/bash-20000901.tar.bz2 276403
+source:  release/bash/bash-20000901-src.tar.bz2 1892899
 [curr]
 version: 2.04
-install: latest/bash/bash-2.04.tar.bz2 277375
-source:  latest/bash/bash-2.04-src.tar.bz2 1815177
+install: release/bash/bash-2.04.tar.bz2 277375
+source:  release/bash/bash-2.04-src.tar.bz2 1815177

@@ -531,22 +543,160 @@ --localstatedir=/var --datadir='$(prefix)/share' All executables in your binary package are stripped (run 'strip' on them). Some makefiles have a install-strip command you can use to do this automatically when you setup your 'installed' tree. - Source packages are extracted in /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: boffo-1.0-1/Makefile.in - boffo-1.0-1/README - boffo-1.0-1/configure - boffo-1.0-1/configure.in - etc... - - + Source packages are extracted in /usr/src. See the Package Source section for more information. In your binary package, include a file /usr/doc/Cygwin/foo-vendor-suffix.README containing (at a minimum) the information needed for an end user to recreate the package. This includes CFLAGS settings, configure parameters, etc. In your binary package include a directory /usr/doc/foo-vendor/ that includes any binary-relevant vendor documentation, such as ChangeLog's, copyright licence's, README's etc. - In your source package include the same foo-vendor-suffix.README as used in the binary package. - Your source package should contain any patches you've applied to it pre-applied. - Include a single file foo-vendor-suffix.patch in your source package, that when applied 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-suffix.patch. To create such a patch you might run diff -Nrup patched-src-dir vendor-src-dir > foo-vendor-suffix.patch To apply the generated patch the user would run (from within the source tree) patch -p1 < ../foo-vendor-suffix.patch If you are not creating your package from an installed virtual root, be sure to check that the file permissions are appropriate. If you have any 'info' documention in your package, run install-info as part of your post-install script If the package has any global settings (ie in files in /etc) that are not overrideable on a per user basis (sshd, as a daemon, is an example of this) do not include the relevant config files in your package. Instead include in your post-install script to install the settings files. Be sure that if you would overwrite an already present file that the user is offered the choice of keeping their own or overwriting with your defaults. Ensure that your package handles binary only systems, textmode only systems, and hybrid systems correctly. + + +Package Source +There are two accepted ways to package the source code for cygwin packages. + Method One + + + 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: + boffo-1.0-1/Makefile.in + boffo-1.0-1/README + boffo-1.0-1/configure + boffo-1.0-1/configure.in + etc... + + 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.exe 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: + boffo-1.0-1/README + boffo-1.0-1/configure + boffo-1.0-1/CYGWIN-PATCHES/boffo-1.0-1.patch + etc... + + 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: + boffo-1.0-1.patch + boffo-1.0-1/README + boffo-1.0-1/configure + etc... + + 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: + boffo-1.0-1.patch + boffo-1.0-1/README + boffo-1.0-1/configure + boffo-1.0-1/configure.in + boffo-1.0-1/Makefile.am + boffo-1.0-1/Makefile.in + boffo-1.0-1/boffo.c + ... + boffo-1.0-1/CYGWIN-PATCHES/boffo.README (cygwin-specific) + boffo-1.0-1/CYGWIN-PATCHES/setup.hint + ... + + + +Method Two + + 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 + + Suppose you've got your boffo package ported to cygwin. It took + some work, but it now builds and runs. Further, suppose that the + boffo-1.0.tar.bz2 file that you downloaded from the boffo homepage + unpacks into boffo-1.0/, so you've been doing all of your work + in ~/sources/boffo-1.0/. That's good. + Place a copy of boffo-1.0.tar.bz2 in ~/sources + copy generic-build-script + into ~/sources/ and rename it boffo-1.0-1.sh. Carefully + adapt this script for your purposes. However, it should auto detect + most of what it needs to know: the package name, vendor version, release + number, etc. + Clean up inside your ~/sources/boffo-1.0/ directory -- make sure + that no files which are generated during the build process are lying around. + Usually, a 'make distclean' will do the trick, but not always. + Ensure that you've put any cygwin-specific readme files, setup.hint files, + etc, into ~/sources/boffo-1.0/CYGWIN-PATCHES/. You can adapt + this generic readme file for this purpose. The build script + expects that the cygwin-specific README file will be named + .../CYGWIN-PATCHES/<package>.README. In this example, it would + be stored as ~/sources/boffo-1.0/CYGWIN-PATCHES/boffo.README. The + build script will ensure that it gets installed as + /usr/doc/Cygwin/boffo-1.0.README + Prepare the staging location for the -src package (yes, do the -src + package first): From the directory above your boffo-1.0 tree (e.g. + ~/sources/ in our example) execute './boffo-1.0-1.sh mkdirs' + Create the -src package: './boffo-1.0-1.sh spkg' + Now, let's go somewhere else and unpack this new -src package: + cd /tmp + tar xvjf ~/sources/boffo-1.0-1-src.tar.bz2 + Finally, rebuild the whole thing (you're still in /tmp): + ./boffo-1.0-1.sh all + (Or, you may want to do each step in 'all' + manually: prep, conf, build, (check), install, strip, pkg, spkg, finish. + Creating a package postinstall script --------------060606070607080906080306--