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: Made many changes to setup.html


>  From: "Robert Collins" <robert.collins@itdomain.com.au>
>  Date: Sun, 16 Dec 2001 18:14:56 +1100
>  
>  From memory - Jonathan's work was a little incorrect. According to
>  http://www.w3.org/TR/html401/struct/links.html#h-12.2.3 id is as equally
>  valid as name, and is required in certain circumstances.

I care less about what the specs say than about whether the HTML
actually works in browsers that many, many people are going to have.
"id=" doesn't work in Netscape 4.7x on Linux (try it!) -- clicking on
a link in the table of contents doesn't bring you to the relevant
section.  If you switch the "id=" to "name=", it works just fine.

Note this excerpt from the section of the spec which you quoted: "
Some older user agents don't support anchors created with the id
attribute."  There's no harm in using "name=" instead of "id=" when
giving a name to an "a" element, so I really believe you should do so.

>  I see no reason to change id to name, as there is no benefit (we're
>  not using entities or character references).

The benefit is making the page work in many browsers where it does not
currently work.

>  Unfortunately I deleted Jonathan's email because I thought it went to
>  the list.... Jonathan could you please resend it to me (the id->name
>  change was all I recall :}).

See attached.

  jik
--- Begin Message ---
How's this?  Note that in addition to adding a section about
postinstall scripts, it also fixes incorrect "id=" tags in the anchors
(they should be "name=" tags).  I can't check this in because I don't
have write access to the repository.

Index: setup.html
===================================================================
RCS file: /cvs/cygwin/htdocs/setup.html,v
retrieving revision 1.23
diff -u -r1.23 setup.html
--- setup.html	2001/11/19 18:10:26	1.23
+++ setup.html	2001/12/12 20:47:31
@@ -21,17 +21,18 @@
   <li><p><a href="#setup.hint">setup.hint</a></p></li>
   <li><p><a href="#setup.ini">setup.ini</a></p></li>
   <li><p><a href="#package_contents">making packages</a></p></li>
+  <li><p><a href="#postinstall">Creating a package postinstall script</a></p></li>
   <li><p><a href="#submitting">Submitting a package</a></p></li>
 </ul>
 
-<h2><a id="naming">Package file naming</a></h2>
+<h2><a name="naming">Package file naming</a></h2>
 <p> Package naming scheme: use the vendor's version
 plus a 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. Binary tarballs are "package-version.tar.bz2" while source tarballs are "package-version-src.tar.bz2". Comparison of versions is done via ASCII sort order. In the event that a package doesn't sort correctly (for example, from ...-9-... to ...-10-..., use the setup.hint current, prev and exp labels to override the inbuilt sort during the transition period.</p>
 
-<h2><a id="sources.redhat.com">Automatic setup.ini generation on sources.redhat.com</a></h2>
+<h2><a 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
 the<tt> latest </tt>and<tt> contrib </tt> directories (possibly more in
@@ -58,7 +59,7 @@
 <p>Test versions are specified via the setup.hint file as described
 below.</p>
 
-<h2><a id="setup.hint"><tt>setup.hint</tt></a></h2>
+<h2><a name="setup.hint"><tt>setup.hint</tt></a></h2>
 
 <p>If the above rules don't work for your package, for some reason, you
 can amend them with a file called<tt> setup.hint </tt> which provides
@@ -144,7 +145,7 @@
 <p>Note colons following keywords are optional in setup.hint file while they
 are mandatory in setup.ini.</p>
 
-<h2><a id="setup.ini"><tt>setup.ini</tt></a></h2>
+<h2><a name="setup.ini"><tt>setup.ini</tt></a></h2>
 
 <p>Note that <tt>setup.ini</tt> is automatically generated.  This
 section is for completeness, not instruction.
@@ -252,7 +253,7 @@
 
 </pre>
 
-<h2><a id="package_contents">Making Packages</a></h2>
+<h2><a name="package_contents">Making Packages</a></h2>
 <p>The files paths within both the -src and the binary package files are quite important. Setup extracts into a predetermined directory, so you must structure your package contents accordingly.</p>
 <p>The following requirements avoid problems that have occured in the past with packages. Thus only skip them if you *know* your package will not recreate that prior problem.</p>
 <ul>
@@ -279,7 +280,31 @@
   <li><p>Ensure that your package handles binary only systems, textmode only systems, and hybrid systems correctly.</p></li>
 </ul>
 
-<h2><a id="submitting">Submitting a package</a></h2>
+<h2><a name="postinstall">Creating a package postinstall script</a></h2>
+
+<p>If your package requires certain commands to be executed after the
+files in the package are installed, include them in a file in the
+package called /etc/postinstall/<var>package</var>.sh or
+/etc/postinstall/<var>package</var>.bat.</p>
+
+<p>If the file's name ends in ".sh", it is executed with the Cygwin
+shell; if it ends in ".bat", it is executed with the DOS command
+interpreter.  If it doesn't end with either of these suffixes, it is
+ignored.</p>
+
+<p>After the script has been run it is renamed by appending the suffix
+".done" to its previous name, to prevent it from being run again the
+next time the user runs the setup program.</p>
+
+<p>Note that the setup program runs all the postinstall scripts after
+all desired packages have been installed, that is, it does not run
+each package's postinstall script immediately after installing that
+package.  Note, furthermore, that the order in which the scripts are
+run is not guaranteed.  Therefore, if your package depends on others
+which have their own postinstall scripts, you cannot assume in your
+script that the other packages' scripts have already been run.</p>
+
+<h2><a name="submitting">Submitting a package</a></h2>
 <p>So you've got a package you want to submit. Follow the following checklist before emailing cygwin-apps@cygwin.com and you'll almost certainly save time.</p>
 <ol>
   <li><p>Propose on cygwin-apps@cygwin.com that you are interested in becoming a package maintainer for package foo. Some packages cannot be distributed via cygwin's setup due to vendor licence limitations. Other packages may not be appropriate for cygwin. This step will save time if, for some reason we cannot accept the package.</p></li>
--- End Message ---

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