Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 1 Apr 2004 14:13:51 -0600
From:      Mark Linimon <linimon@lonesome.com>
To:        FreeBSD-gnats-submit@FreeBSD.org, freebsd-doc@FreeBSD.org
Cc:        Oliver Eikemeier <eikemeier@fillmore-labs.com>
Subject:   Re: docs/64144: [patch] document procedure to add a new ports category to Committer's Guide
Message-ID:  <200404011413.51013.linimon@lonesome.com>
In-Reply-To: <Pine.LNX.4.44.0403301853580.6616-100000@pancho>
References:  <Pine.LNX.4.44.0403301853580.6616-100000@pancho>

next in thread | previous in thread | raw e-mail | index | archive | help
Here is an updated (hopefully final) version of the patch.  It is still
vague on the detail of getting http://www.FreeBSD.org/ports/ updated,
but since that seems to be still under discussion, IMHO we should
go ahead and commit what's here and update that detail once that
discussion is resolved.

Index: article.sgml
===================================================================
RCS 
file: /mnt/FreeBSD/dcvs/doc/en_US.ISO8859-1/articles/committers-guide/article.sgml,v
retrieving revision 1.180
diff -u -r1.180 article.sgml
--- article.sgml	27 Feb 2004 15:23:15 -0000	1.180
+++ article.sgml	1 Apr 2004 20:09:17 -0000
@@ -2516,6 +2516,179 @@
       </qandadiv>
 
       <qandadiv>
+	<title>Creating a New Category</title>
+
+	<qandaentry>
+	  <question>
+	    <para>What is the procedure for creating a new category?</para>
+	  </question>
+
+	  <answer>
+	    <para>A developer who wishes to propose a new category
+	      should submit a detailed rationale for the new category,
+	      including why existing categories are not sufficient,
+	      and the list of ports proposed to move.</para>
+
+	    <para>Before submitting, keep in mind that there is a fair
+	      amount of work involved from multiple parties; that the
+	      changes affect everyone who wants to keep up-to-date with
+	      the entire ports tree; and that such proposals tend to
+	      attract controversy.</para>
+	  </answer>
+	</qandaentry>
+
+	<qandaentry>
+	  <question>
+	    <para>What do I need to do?</para>
+	  </question>
+
+	  <answer>
+	    <para>The procedure is a strict superset of the one to
+	      repocopy individual ports (see above).</para>
+
+	    <para>File a PR in <application>GNATS</application>, listing the
+	      reasons for the category request.  Preferably, this should
+	      also include patches for <filename>Makefile</filename>s for
+	      the old ports, the <filename>Makefile</filename>s for their
+	      old categories, and the <makevar>VALID_CATEGORIES</makevar>
+	      definition in <filename>ports/Mk/bsd.port.mk</filename>.
+	      Assign the PR to the &a.portmgr; (as <literal>portmgr</literal>).
+	      If they approve it, it will be reassigned to &a.cvs; (as
+	      <literal>cvs</literal>), who will do a repository copy from
+	      the old to the new locations, and reassign the PR back to you.
+	      Once everything is done, perform the following steps:</para>
+
+	      <procedure>
+		<step>
+		  <para>Upgrade each copied port's
+		    <filename>Makefile</filename>.  Do not connect the
+		    new category to the build yet.</para>
+
+		  <para>To do this, you will need to:
+		    <procedure>
+		      <step>
+			<para>Change the port's <makevar>CATEGORIES</makevar>
+			  (this was the point of the exercise, remember?)
+			  The new category should be listed
+			  <emphasis>first</emphasis>.  This will help to
+			  ensure that the the <makevar>PKGORIGIN</makevar>
+			  is correct.</para>
+		      </step>
+
+		      <step>
+			<para>Run a <command>make describe</command>.  Since
+			  the top-level <command>make index</command> that
+			  you will be running in a few steps is an interation
+			  of <command>make describe</command> over the entire
+			  ports hierarchy, catching any errors here will
+			  save you having to re-run that step later on.</para>
+		      </step>
+
+		      <step>
+			<para>If you want to be really thorough, now might
+			  be a good time to run &man.portlint.1;.</para>
+		      </step>
+		    </procedure>
+		</step>
+
+		<step>
+		  <para>Check that the <makevar>PKGORIGIN</makevar>s are
+		    correct.  The ports system uses each port's
+		    <makevar>CATEGORIES</makevar> entry to create
+		    its <makevar>PKGORIGIN</makevar>, which is used to
+		    connect installed packages to the port directory they
+		    were built from. If this entry is wrong, common port
+		    tools like &man.pkg.version.1; and
+		    &man.portupgrade.1; fail.</para>
+
+		  <para>To do this, use the <filename>chkorigin.sh</filename>
+		    tool, as follows: <command>env
+		    PORTSDIR=<replaceable>/path/to/ports</replaceable>
+		    sh -e 
<replaceable>/path/to/ports</replaceable>/Tools/scripts/chkorigin.sh
+		    </command>.  This will check <emphasis>every</emphasis>
+		    port in the ports tree, even those not connected to the
+		    build, so you can run it directly after the repocopy.
+		    Hint: do not forget to look at the
+		    <makevar>PKGORIGIN</makevar>s of any slave ports of the
+		    ports you just repocopied!</para>
+		</step>
+
+		<step>
+		  <para>On your own local system, test the proposed
+		    changes: first, comment out the
+		    <makevar>SUBDIR</makevar> entries in the old
+		    ports' categories' <filename>Makefile</filename>s;
+		    then, enable building the new category in
+		    <filename>ports/Makefile</filename>.
+		    Run <command>make checksubdirs</command> in the
+		    affected category directories to check the
+		    <makevar>SUBDIR</makevar> entries.  Next, in
+		    the <filename class="directory">ports/</filename>
+		    directory, run <command>make index</command>.  This
+		    can take over 40 minutes on even modern systems;
+		    however, it is a necessary step to prevent problems
+		    for other people.</para>
+		</step>
+
+		<step>
+		  <para>Once this is done, you can commit the
+		    updated <filename>ports/Makefile</filename> to
+		    connect the new category to the build; and also
+		    commit the <filename>Makefile</filename> changes
+		    for the old category or categories.  The new
+		    category's <filename>pkg/COMMENT</filename>
+		    can be committed, too.</para>
+		</step>
+
+		<step>
+		  <para>Change all the affected module entries in
+		    <filename>CVSROOT-ports/modules</filename>.</para>
+		</step>
+
+		<step>
+		  <para>Add appropriate entries to
+		    <filename>ports/MOVED</filename>.</para>
+		</step>
+
+		<step>
+		  <para>Update the instructions for &man.cvsup.1; by
+		    modifying <filename>distrib/cvsup/sup/README</filename>
+		    and adding the following files into
+		    <filename>cvsup/sup/ports-categoryname</filename>:
+		    <filename>list.cvs</filename> and
+		    <filename>releases</filename>.</para>
+		</step>
+
+		<step>
+		  <para>Submit a docs PR to add the new category both to the
+		    <ulink 
url="../../books/porters-handbook/makefile-categories.html#PORTING-CATEGORIES">
+		    Porter's Handbook</ulink> and to the file
+		    <filename>www/en/ports/categories</filename>.</para>
+		</step>
+
+		<step>
+		  <para>Submit a www PR to request that the <ulink
+		    url="../../../../ports/index.html">ports web pages</ulink>
+		    be updated to reflect the new category.  Currently
+		    this requires an import of
+		    <filename>/usr/ports/INDEX</filename> into the www tree
+		    (suggestions are welcome about how to get rid of this
+		    dependency).  The responsibility for doing this is not
+		    yet well established.</para>
+		</step>
+
+		<step>
+		  <para>Only once all the above have been done, and
+		    no one is any longer reporting problems with the
+		    new ports, should the old ports be deleted from
+		    their previous locations in the repository.</para>
+		</step>
+	      </procedure>
+	  </answer>
+	</qandaentry>
+      </qandadiv>
+
+      <qandadiv>
 	<title>Miscellaneous Questions</title>
 
 	<qandaentry>



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200404011413.51013.linimon>