docs/121197: [patch] edits to books/porters-handbook
Chess Griffin
chess at chessgriffin.com
Fri Feb 29 02:20:02 UTC 2008
>Number: 121197
>Category: docs
>Synopsis: [patch] edits to books/porters-handbook
>Confidential: no
>Severity: non-critical
>Priority: low
>Responsible: freebsd-doc
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: change-request
>Submitter-Id: current-users
>Arrival-Date: Fri Feb 29 02:20:01 UTC 2008
>Closed-Date:
>Last-Modified:
>Originator: Chess Griffin
>Release: 7.0-RELEASE
>Organization:
>Environment:
FreeBSD bsdbob.localdomain 7.0-RELEASE FreeBSD 7.0-RELEASE #1: Mon Feb 25 19:09:06 EST 2008 chess at bsdbob.localdomain:/usr/obj/usr/src/sys/CHESS i38
>Description:
Attached are some minor edits plus one small addition to the Porter's Handbook.
>How-To-Repeat:
>Fix:
Patch attached with submission follows:
--- book.sgml.orig 2008-02-28 19:06:47.000000000 -0500
+++ book.sgml 2008-02-28 21:09:37.000000000 -0500
@@ -2465,10 +2465,10 @@
hereon.</para>
<para>A little background first. OpenBSD has a neat feature
- inside both <makevar>DISTFILES</makevar> and
- <makevar>PATCHFILES</makevar> variables, both files and
- patches can be postfixed with <literal>:n</literal>
- identifiers where <literal>n</literal> both can be
+ inside the <makevar>DISTFILES</makevar> and
+ <makevar>PATCHFILES</makevar> variables which allows files
+ and patches to be postfixed with <literal>:n</literal>
+ identifiers, where <literal>n</literal> both can be
<literal>[0-9]</literal> and denote a group designation.
For example:</para>
@@ -2489,7 +2489,7 @@
as hell where <filename>beta</filename> is carried by all
sites in <makevar>MASTER_SITES</makevar>, and
<filename>alpha</filename> can only be found in the 20th
- site. It would be such a waste to check all of them if
+ site. It would be such a waste to check all of them if the
maintainer knew this beforehand, would it not? Not a good
start for that lovely weekend!</para>
@@ -3174,24 +3174,25 @@
challenge for port maintainers</ulink> section.</para>
<para>Changes to the port will be sent to the maintainer of
- a port for a review and an approval before being committed.
- If the maintainer does not respond to an update
- request after two weeks (excluding major public
- holidays), then that is considered a maintainer timeout, and the
- update may be made without explicit maintainer approval. If the
- maintainer does not respond within three months, then that
- maintainer is considered absent without leave, and can be
- replaced as the maintainer of the particular port in question.
- Exceptions to this are anything maintained by the &a.portmgr;, or
- the &a.security-officer;. No unauthorized commits may ever be
- made to ports maintained by those groups.</para>
+ a port for review and approval before being committed. If
+ the maintainer does not respond to an update request after
+ two weeks (excluding major public holidays), then that is
+ considered a maintainer timeout, and the update may be made
+ without explicit maintainer approval. If the maintainer
+ does not respond within three months, then that maintainer
+ is considered absent without leave, and can be replaced as
+ the maintainer of the particular port in question.
+ Exceptions to this are anything maintained by the
+ &a.portmgr;, or the &a.security-officer;. No unauthorized
+ commits may ever be made to ports maintained by those
+ groups.</para>
<para>We reserve the right to modify the maintainer's submission
to better match existing policies and style of the Ports
Collection without explicit blessing from the submitter.
Also, large infrastructural changes can result in
- a port being modified without maintainer's consent.
- This kind of changes will never affect the port's
+ a port being modified without the maintainer's consent.
+ These kinds of changes will never affect the port's
functionality.</para>
<para>The &a.portmgr; reserves the right to revoke or override
@@ -4180,14 +4181,16 @@
under <makevar>PREFIX</makevar>.</para>
<para>Two macros exists for this situation. The advantage of using
- these macros instead of <command>cp</command> is that they guarantee
- proper file ownership and permissions on target files. First macro,
- <makevar>COPYTREE_BIN</makevar>, will set all the installed files to
- be executable, thus being suitable for installing into
- <filename><makevar>PREFIX</makevar>/bin</filename>. The second
- macro, <makevar>COPYTREE_SHARE</makevar>, does not set executable
- permissions on files, and is therefore suitable for installing files
- under <filename><makevar>PREFIX</makevar>/share</filename>
+ these macros instead of <command>cp</command> is that they
+ guarantee proper file ownership and permissions on target
+ files. The first macro, <makevar>COPYTREE_BIN</makevar>,
+ will set all the installed files to be executable, thus
+ being suitable for installing into
+ <filename><makevar>PREFIX</makevar>/bin</filename>. The
+ second macro, <makevar>COPYTREE_SHARE</makevar>, does not
+ set executable permissions on files, and is therefore
+ suitable for installing files under
+ <filename><makevar>PREFIX</makevar>/share</filename>
target.</para>
<programlisting>post-install:
@@ -8591,6 +8594,12 @@
<para>The packing list still has to be tidied up by hand as
stated above.</para>
+ <para>Another tool that might be used to create a
+ <filename>pkg-plist</filename> as a starting point is
+ <application>ports-mgmt/genplist</application>. As with any
+ automated tool, the resulting <filename>pkg-plist</filename>
+ should be checked and manually edited as needed.</para>
+
</sect1>
</chapter>
@@ -11809,7 +11818,7 @@
<row>
<entry>7.0-CURRENT after
RFC 3678 API support added to the IPv4 stack.
- Legacy RFC 1724 behaviour of the IP_MULTICAST_IF
+ Legacy RFC 1724 behavior of the IP_MULTICAST_IF
ioctl has now been removed; 0.0.0.0/8 may no longer
be used to specify an interface index.
struct ipmreqn should be used instead.</entry>
>Release-Note:
>Audit-Trail:
>Unformatted:
More information about the freebsd-doc
mailing list