Date: Sat, 1 Mar 2008 00:00:04 GMT From: Chess Griffin <chess@chessgriffin.com> To: freebsd-doc@FreeBSD.org Subject: Re: docs/121197: [patch] edits to books/porters-handbook Message-ID: <200803010000.m21004Jq001344@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR docs/121197; it has been noted by GNATS. From: Chess Griffin <chess@chessgriffin.com> To: bug-followup@FreeBSD.org, chess@chessgriffin.com Cc: Subject: Re: docs/121197: [patch] edits to books/porters-handbook Date: Fri, 29 Feb 2008 18:59:41 -0500 --huq684BweRXVnRxX Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline One more edit suggested me by someone off-list. Thanks. -- Chess Griffin GPG Public Key: 0x0C7558C3 http://www.chessgriffin.com --huq684BweRXVnRxX Content-Type: text/x-diff; charset=iso-8859-1 Content-Disposition: attachment; filename="porterspatch.diff" --- book.sgml.orig 2008-02-28 19:06:47.000000000 -0500 +++ book.sgml 2008-02-29 18:57:03.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,7 +3174,7 @@ 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. + 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 @@ -3191,7 +3191,7 @@ 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 + These kinds of changes will never affect the port's functionality.</para> <para>The &a.portmgr; reserves the right to revoke or override @@ -4179,9 +4179,9 @@ directory tree from <makevar>WRKSRC</makevar> to a target directory under <makevar>PREFIX</makevar>.</para> - <para>Two macros exists for this situation. The advantage of using + <para>Two macros exist 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, + 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 @@ -8591,6 +8591,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 an initial + <filename>pkg-plist</filename> is <filename + role="package">ports-mgmt/genplist</filename>. As with any + automated tool, the resulting <filename>pkg-plist</filename> + should be checked and manually edited as needed.</para> + </sect1> </chapter> @@ -11809,7 +11815,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> --huq684BweRXVnRxX--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200803010000.m21004Jq001344>