This is the mail archive of the cygwin-apps@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: strange source packaging?


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
--- setup-old.html	Sun Apr 21 22:45:52 2002
+++ setup.html	Sun Apr 21 22:57:14 2002
@@ -22,7 +22,7 @@
 
 <!-- ================================================================== -->
 <!--                                                                    -->
-<!--			     Left Sidebar                               -->
+<!--                         Left Sidebar                               -->
 <!--                                                                    -->
 
 <table align=left border=1 cellspacing=0 cellpadding=8 width="20%" bgcolor="eeeeee">
@@ -94,11 +94,11 @@
 </ul>
 
 <h2><a id="naming" name="naming">Package file naming</a></h2>
-<p> Package naming scheme: use the vendor's version plus a suffix for
+<p> 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.</p>
+The first release of a package should have a -1 release suffix.</p>
 
 <p>A complete package currently consists of three files:</p>
 <ul>
@@ -107,18 +107,18 @@
 <li>a setup.hint file
 </ul>
 
-<p>Binary tar files are named "package-version.tar.bz2".  They generally
+<p>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 <a
 href="#package_contents">making packages</a> section below for more
 details on how to generate a binary tar file.</p>
 
-<p>Source tar files are named "package-version-src.tar.bz2".  Source tar files
+<p>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 <em>not</em> optional.  See the <a
-href="#package_contents"> making packages</a> section below for more
+href="#srcpackage_contents"> making packages</a> section below for more
 details on the contents of a -src tar file..</p>
 
 <p>The setup.hint file is discussed <a href="#setup.hint">below</a>.
@@ -126,22 +126,31 @@
 <h2><a id="sources.redhat.com" name="sources.redhat.com">Automatic setup.ini generation on sources.redhat.com</a></h2>
 
 <p>A script runs on sources.redhat.com which collects information from
-(currently) the <tt>latest</tt> and <tt>contrib</tt> directories in the
+(currently) the <tt>release</tt> directory in the
 ftp download area.  Information from subdirectories of these directories
 is parsed to automatically generate the default <a href="#setup.ini">
 setup.ini</a> 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.</p>
 
-<p>Packages are grouped by directory under <tt>latest</tt> or
-<tt>contrib</tt>.  The directory name is typically the same as the
-package name.  For example, the <tt>boffo</tt> package will live in the
-<tt>boffo</tt> subdirectory.  Exceptions to this rule are historical.
-All new packages will follow the rule of package name == directory name.
+<p>Packages are grouped by directory under <tt>release</tt>.  The directory
+name is the same as the package name.  For example, the <tt>boffo</tt> package
+will live in the <tt>boffo</tt> 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 <tt>release/</tt>:
+<pre><tt>
+  release/
+  release/boffo/
+  release/boffo/&lt;boffo files&gt;
+  release/boffo/boffo-devel/
+  release/boffo/boffo-devel/&lt;boffo-devel file&gt;
+</tt></pre>
 
 <p>Each directory contains <a href="#naming">source and binary tar
 files</a> which have been been compressed using bzip2.  The required <a
-href="#naming">format of these filenames</a> is: <tt>package-version[<i>-src</i>].tar.bz2</tt> .
+href="#naming">format of these filenames</a> is:
+<tt>package-version-release[<i>-src</i>].tar.bz2</tt> .
 The contents of these files is discussed <a href="#package_contents">
 below</a>.
 
@@ -150,10 +159,13 @@
 
 <p>The version number <b>must</b> start with a digit and must adhere to
 the rules in <a href="#naming">package file naming</a> 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 <a href="#setup.hint">setup.hint</a> for exceptions to
-this rule).</p>
+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 <a href="#setup.hint">setup.hint</a> 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.</p>
 
 <p>The <i>-src</i> component of the filename is added to files which
 contain source code.</p>
@@ -162,7 +174,7 @@
 tar file, the "source" tar file, and the "setup.hint" file, e.g.:
 
 <pre>
-bash$ ls contrib/boffo
+bash$ ls release/boffo
 boffo-1.0-1.tar.bz2  boffo-1.0-1-src.tar.bz2  setup.hint
 </pre>
 
@@ -228,8 +240,8 @@
 ordering.  So, e.g., if you had previously released <tt>boffo-0.9-1</tt>
 and now have a new <tt>boffo-1.0-1</tt>, the version numbering is
 obvious and there is no need to use <tt>curr</tt> or <tt>prev</tt>.  It
-is obvious that <tt>boffo-1.0-1</tt> is newer than <tt>boffo-0.9-1</tt> and the setup.ini
-generator will do the right thing in this case.</p>
+is obvious that <tt>boffo-1.0-1</tt> is newer than <tt>boffo-0.9-1</tt> and
+the setup.ini generator will do the right thing in this case.</p>
 
 <p>However, if you had discovered a serious error in the <tt>boffo-1.0</tt>
 release, and then decided that you want to drop back to <tt>boffo-0.9-1</tt>, you
@@ -297,13 +309,13 @@
 description, e.g., this is incorrect:
 
 <pre>
-<tt>sdesc:	"boffo: A whackamole simulation in ASCII art"</tt>
+<tt>sdesc:      "boffo: A whackamole simulation in ASCII art"</tt>
 </pre>
 
 This is correct:
 
 <pre>
-<tt>sdesc:	"A whackamole simulation in ASCII art"</tt>
+<tt>sdesc:      "A whackamole simulation in ASCII art"</tt>
 </pre>
 
 <p>Quote text that takes up several lines e.g.:</p>
@@ -388,7 +400,7 @@
 <p>Multiple packages are separated by spaces.  Do not enclose multiple
 package names within quotation marks.</p>
 
-<p>Here's an example of a complete <i>contrib/current/boffo/setup.hint</i>:</p>
+<p>Here's an example of a complete <i>release/boffo/setup.hint</i>:</p>
 <pre>
 <tt>
     category: Games Text
@@ -428,7 +440,7 @@
 
 <p><tt>setup-version: <i>number</i></tt></p>
 
-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
 
 </pre>
 
@@ -531,22 +543,160 @@
   --localstatedir=/var
   --datadir='$(prefix)/share'</pre></li>
   <li><p>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.</p></li>
-  <li><p>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:<pre><tt>  boffo-1.0-1/Makefile.in
-  boffo-1.0-1/README
-  boffo-1.0-1/configure
-  boffo-1.0-1/configure.in
-  etc...
-</tt></pre></li>
-
+  <li><p>Source packages are extracted in /usr/src.  See the <a href="#srcpackage_contents">Package Source</a> section for more information.
   <li><p>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.</p></li>
   <li><p>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.</p></li>
-  <li><p>In your source package include the same foo-vendor-suffix.README as used in the binary package.</p></li>
-  <li><p>Your source package should contain any patches you've applied to it pre-applied.</p></li>
-  <li><p>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.<p><p>To create such a patch you might run <tt>diff -Nrup patched-src-dir vendor-src-dir &gt; foo-vendor-suffix.patch</tt></p><p>To apply the generated patch the user would run (from within the source tree) <tt>patch -p1 &lt; ../foo-vendor-suffix.patch</tt></p></li>
   <li><p>If you are not creating your package from an installed virtual root, be sure to check that the file permissions are appropriate.</p></li>
   <li><p>If you have any 'info' documention in your package, run install-info as part of your post-install script</p></li>
   <li><p>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.</p></li>
   <li><p>Ensure that your package handles binary only systems, textmode only systems, and hybrid systems correctly.</p></li>
+</ul>
+
+<h2><a id="srcpackage_contents" name="srcpackage_contents">Package Source</a></h2>
+<p>There are two accepted ways to package the source code for cygwin packages.
+<h3>Method One</h3>
+
+<ul>
+  <li><p>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:
+<pre><tt>  boffo-1.0-1/Makefile.in
+  boffo-1.0-1/README
+  boffo-1.0-1/configure
+  boffo-1.0-1/configure.in
+  etc...
+</tt></pre></li>
+  <li><p>In your source package include the same foo-vendor-suffix.README
+  as used in the binary package.</p></li>
+  <li><p>Your source package already be patched with any necessary cygwin
+  specific changes.  The user should be able to just ./configure; make; and go.</p></li>
+  <li><p>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 : <tt>/usr/src/foo-vendor-release.patch</tt>
+  (that is, since setup.exe extracts everything into <tt>/usr/src</tt>,
+  the patch should be a &quot;top level&quot; member of the -src tarball.)<p>
+  <p>Optionally, this patch could also unpack inside the source tree:
+<pre><tt>  boffo-1.0-1/README
+  boffo-1.0-1/configure
+  boffo-1.0-1/CYGWIN-PATCHES/boffo-1.0-1.patch
+  etc...
+</tt></pre>
+  However, that tends to complicate actually <b>creating</b> 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:
+<pre><tt>  boffo-1.0-1.patch
+  boffo-1.0-1/README
+  boffo-1.0-1/configure
+  etc...
+</tt></pre>
+  To create the patch file described above, you might run
+  <pre><tt>  diff -Nrup vendor-src-dir patched-src-dir &gt; foo-vendor-release.patch</tt></pre>
+  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)
+  <pre><tt>  patch -R -p1 &lt; ../foo-vendor-release.patch</tt></pre></p></li>
+  <li><p>In general, any cygwin-specific &quot;packaging&quot; 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.
+  <li><p>So, returning to the boffo example, boffo-1.0-1-src.tar.bz2 would contain:
+<pre><tt>  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
+  ...
+</tt></pre>
+</ul>
+
+<h3>Method Two</h3>
+<ul>
+  <li><p>In a packaging technique inspired by rpms and debs, you may create a
+  -src tarball which simply contains:
+  <ol>
+    <li><p><tt>foo-vendor.tar.[gz|bz2]</tt>:  The original source tarball,
+    exactly as downloaded from the original vendor.
+    <li><p><tt>foo-vendor-release.patch</tt>:  the patch file as described in
+    Method One, above.</p>
+    <li><p><tt>foo-vendor-release.sh</tt>:  A build script that drives the
+    entire unpacking, configuration, build, and packaging (binary and -src)
+    process.</p>
+  </ol>
+  <li><p>You can adapt <a href="generic-readme">this</a>
+  generic readme file for script-driven -src packages.</p>
+  <li><p><a href="generic-build-script">Here</a> 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
+  <b><i>Initial packaging procedure</i></b> below.  But first, a few facts:</p>
+  <ul>
+    <li><p>The buildscript will autodetect the package name, vendor version,
+    and release number from its own filename.</p>
+    <li><p>When the buildscript is used to compile the package, all building
+    occurs within a hidden subdirectory inside the source tree:
+    <tt>boffo-1.0/.build/</tt></p>
+    <li><p>To create the binary package, the script redirects 'make install'
+    into a hidden subdirectory <tt>boffo-1.0/.inst/</tt>, creating
+    a faux tree <tt>boffo-1.0/.inst/usr/bin</tt>, etc.  This faux tree is
+    tar'ed up into the new binary package.</p>
+    <li><p>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 <tt>boffo-1.0/.sinst/</tt>.  The contents of this
+    subdirectory are tar'ed up into the new -src package.</p>
+    <li><p>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 <tt>.build</tt> subdirectory.  The jbigkit -src
+    package uses GNU shtool's mkshadow to do this.</p>
+    <li><p><tt>generic-build-script</tt> is <b>not</b> a one-size-fits-all
+    solution.  It <b>must</b> be customized for your package.</p>
+  </ul>
+  <li><p><b><i>Initial packaging procedure, script-based</i></b></p>
+  <ul>
+    <li><p>Suppose you've got your boffo package ported to cygwin.  It took
+    some work, but it now builds and runs.  Further, suppose that the
+    <tt>boffo-1.0.tar.bz2</tt> file that you downloaded from the boffo homepage
+    unpacks into <tt>boffo-1.0/</tt>, so you've been doing all of your work
+    in <tt>~/sources/boffo-1.0/</tt>.  That's good.</p>
+    <li><p>Place a copy of <tt>boffo-1.0.tar.bz2</tt> in <tt>~/sources</tt>
+    <li>copy <a href="generic-build-script"><tt>generic-build-script</tt></a>
+    into <tt>~/sources/</tt> and rename it <tt>boffo-1.0-1.sh</tt>.  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.</p>
+    <li><p>Clean up inside your <tt>~/sources/boffo-1.0/</tt> directory -- make sure
+    that no files which are generated during the build process are lying around.
+    Usually, a '<tt>make distclean</tt>' will do the trick, but not always.</p>
+    <li><p>Ensure that you've put any cygwin-specific readme files, setup.hint files,
+    etc, into <tt>~/sources/boffo-1.0/CYGWIN-PATCHES/</tt>.  You can adapt
+    <a href="generic-readme">this generic readme file</a> for this purpose.  The build script
+    expects that the cygwin-specific README file will be named
+    <tt>.../CYGWIN-PATCHES/&lt;package&gt;.README</tt>.  In this example, it would
+    be stored as <tt>~/sources/boffo-1.0/CYGWIN-PATCHES/boffo.README</tt>.  The
+    build script will ensure that it gets installed as
+    <tt>/usr/doc/Cygwin/boffo-1.0.README</tt>
+    <li>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.
+    <tt>~/sources/</tt> in our example) execute '<tt>./boffo-1.0-1.sh mkdirs</tt>'</p>
+    <li><p>Create the -src package: '<tt>./boffo-1.0-1.sh spkg</tt>'</p>
+    <li><p>Now, let's go somewhere else and unpack this new -src package:
+    <pre><tt>  cd /tmp
+  tar xvjf ~/sources/boffo-1.0-1-src.tar.bz2</tt></pre></p>
+    <li><p>Finally, rebuild the whole thing (you're still in /tmp):
+    <pre><tt>  ./boffo-1.0-1.sh all</tt></pre>
+    (Or, you may want to do each step in 'all'
+    manually: prep, conf, build, (check), install, strip, pkg, spkg, finish.</p>
+  </ul>
 </ul>
 
 <h2><a id="postinstall" name="postinstall">Creating a package postinstall script</a></h2>

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]