pkgsrc-Changes-HG archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
[pkgsrc/trunk]: pkgsrc/doc/guide/files No leading or trailing whitespace in <...
details: https://anonhg.NetBSD.org/pkgsrc/rev/42fc201375e3
branches: trunk
changeset: 496934:42fc201375e3
user: wiz <wiz%pkgsrc.org@localhost>
date: Sat Jul 16 19:21:50 2005 +0000
description:
No leading or trailing whitespace in <para>.
diffstat:
doc/guide/files/fixes.xml | 398 +++++++++++++++++++++++-----------------------
1 files changed, 199 insertions(+), 199 deletions(-)
diffs (truncated from 1091 to 300 lines):
diff -r 2e0f6f63be06 -r 42fc201375e3 doc/guide/files/fixes.xml
--- a/doc/guide/files/fixes.xml Sat Jul 16 19:10:37 2005 +0000
+++ b/doc/guide/files/fixes.xml Sat Jul 16 19:21:50 2005 +0000
@@ -1,4 +1,4 @@
-<!-- $NetBSD: fixes.xml,v 1.24 2005/06/17 12:55:25 wiz Exp $ -->
+<!-- $NetBSD: fixes.xml,v 1.25 2005/07/16 19:21:50 wiz Exp $ -->
<chapter id="fixes"> <?dbhtml filename="fixes.html"?>
<title>Notes on fixes for packages</title>
@@ -9,7 +9,7 @@
<sect2 id="pulling-vars-from-etc-mk.conf">
<title>How to pull in variables from /etc/mk.conf</title>
- <para> The problem with package-defined variables that can be
+ <para>The problem with package-defined variables that can be
overridden via <varname>MAKECONF</varname> or
<filename>/etc/mk.conf</filename> is that &man.make.1; expands a
variable as it is used, but evaluates preprocessor like
@@ -17,14 +17,14 @@
use any variable (which may be set in
<filename>/etc/mk.conf</filename>) in one of the .if*
statements, the file <filename>/etc/mk.conf</filename> must be
- included before that .if* statement. </para>
+ included before that .if* statement.</para>
- <para> Rather than have a number of ad-hoc ways of including
+ <para>Rather than have a number of ad-hoc ways of including
<filename>/etc/mk.conf</filename>, should it exist, or
<varname>MAKECONF</varname>, should it exist, include the
<filename>pkgsrc/mk/bsd.prefs.mk</filename> file in the package
Makefile before any preprocessor-like .if, .ifdef, or .ifndef
- statements: </para>
+ statements:</para>
<programlisting>.include "../../mk/bsd.prefs.mk"
@@ -32,7 +32,7 @@
...
.endif</programlisting>
- <para> If you wish to set the <varname>CFLAGS</varname> variable
+ <para>If you wish to set the <varname>CFLAGS</varname> variable
in <filename>/etc/mk.conf</filename> please make sure to use:
<programlisting>CFLAGS+= -your -flags</programlisting>
@@ -41,118 +41,118 @@
<quote>+</quote>) may lead to problems with packages that need
to add their own flags. Also, you may want to take a look at
the <pkg>devel/cpuflags</pkg> package if you're interested in
- optimization for the current CPU. </para>
+ optimization for the current CPU.</para>
</sect2>
<sect2 id="where-to-install-documentation">
<title>Where to install documentation</title>
- <para> Documentation should be installed into
+ <para>Documentation should be installed into
<filename>${PREFIX}/share/doc/${PKGBASE}</filename> or
<filename>${PREFIX}/share/doc/${PKGNAME}</filename> (the
- latter includes the version number of the package). </para>
+ latter includes the version number of the package).</para>
</sect2>
<sect2 id="restricted-packages">
<title>Restricted packages</title>
- <para> Some licenses restrict how software may be re-distributed.
+ <para>Some licenses restrict how software may be re-distributed.
In order to satisfy these restrictions, the package system
defines five make variables that can be set to note these
- restrictions: </para>
+ restrictions:</para>
<itemizedlist>
<listitem>
<para><varname>RESTRICTED</varname></para>
- <para> This variable should be set whenever a restriction
+ <para>This variable should be set whenever a restriction
exists (regardless of its kind). Set this variable to a
- string containing the reason for the restriction. </para>
+ string containing the reason for the restriction.</para>
</listitem>
<listitem>
<para><varname>NO_BIN_ON_CDROM</varname></para>
- <para> Binaries may not be placed on CD-ROM. Set this
- variable to <varname>${RESTRICTED}</varname> whenever a
- binary package may not be included on a CD-ROM. </para>
+ <para>Binaries may not be placed on CD-ROM. Set this
+ variable to <varname>${RESTRICTED}</varname> whenever a
+ binary package may not be included on a CD-ROM.</para>
</listitem>
<listitem>
<para><varname>NO_BIN_ON_FTP</varname></para>
- <para> Binaries may not be placed on an FTP server. Set
- this variable to <varname>${RESTRICTED}</varname>
- whenever a binary package may not not be made available
- on the Internet. </para>
+ <para>Binaries may not be placed on an FTP server. Set
+ this variable to <varname>${RESTRICTED}</varname>
+ whenever a binary package may not not be made available
+ on the Internet.</para>
</listitem>
<listitem>
<para><varname>NO_SRC_ON_CDROM</varname></para>
- <para> Distfiles may not be placed on CD-ROM. Set this
+ <para>Distfiles may not be placed on CD-ROM. Set this
variable to <varname>${RESTRICTED}</varname> if
re-distribution of the source code or other distfile(s) is
- not allowed on CD-ROMs. </para>
+ not allowed on CD-ROMs.</para>
</listitem>
<listitem>
<para><varname>NO_SRC_ON_FTP</varname></para>
- <para> Distfiles may not be placed on FTP. Set this variable
+ <para>Distfiles may not be placed on FTP. Set this variable
to <varname>${RESTRICTED}</varname> if re-distribution of
the source code or other distfile(s) via the Internet is not
- allowed. </para>
+ allowed.</para>
</listitem>
</itemizedlist>
- <para> Please note that the use of <varname>NO_PACKAGE</varname>,
+ <para>Please note that the use of <varname>NO_PACKAGE</varname>,
<varname>IGNORE</varname>, <varname>NO_CDROM</varname>, or other
generic make variables to denote restrictions is deprecated,
because they unconditionally prevent users from generating
- binary packages! </para>
+ binary packages!</para>
</sect2>
<sect2 id="dependencies">
<title>Handling dependencies</title>
- <para> Your package may depend on some other package being present
+ <para>Your package may depend on some other package being present
- and there are various ways of expressing this
dependency. pkgsrc supports the <varname>BUILD_DEPENDS</varname>
and <varname>DEPENDS</varname> definitions, as well as
dependencies via <filename>buildlink3.mk</filename>, which is
the preferred way to handle dependencies, and which uses the
variables named above. See <xref linkend="buildlink"/> for more
- information. </para>
+ information.</para>
- <para> The basic difference between the two variables is as
+ <para>The basic difference between the two variables is as
follows: The <varname>DEPENDS</varname> definition registers
that pre-requisite in the binary package so it will be pulled in
when the binary package is later installed, whilst the
<varname>BUILD_DEPENDS</varname> definition does not, marking a
dependency that is only needed for building the package.
- </para>
+</para>
- <para> This means that if you only need a package present whilst
+ <para>This means that if you only need a package present whilst
you are building, it should be noted as a
- <varname>BUILD_DEPENDS</varname>. </para>
+ <varname>BUILD_DEPENDS</varname>.</para>
- <para> The format for a <varname>BUILD_DEPENDS</varname> and a
- <varname>DEPENDS</varname> definition is: </para>
+ <para>The format for a <varname>BUILD_DEPENDS</varname> and a
+ <varname>DEPENDS</varname> definition is:</para>
<programlisting><pre-req-package-name>:../../<category>/<pre-req-package></programlisting>
- <para> Please note that the <quote>pre-req-package-name</quote>
+ <para>Please note that the <quote>pre-req-package-name</quote>
may include any of the wildcard version numbers recognized by
- &man.pkg.info.1;. </para>
+ &man.pkg.info.1;.</para>
<orderedlist>
<listitem>
- <para> If your package needs another package's binaries or
+ <para>If your package needs another package's binaries or
libraries to build or run, and if that package has a
<filename>buildlink3.mk</filename> file available, use it:
- </para>
+</para>
<programlisting>
.include "../../graphics/jpeg/buildlink3.mk"
@@ -160,67 +160,67 @@
</listitem>
<listitem>
- <para> If your package needs to use another package to build
+ <para>If your package needs to use another package to build
itself and there is no <filename>buildlink3.mk</filename>
file available, use the <varname>BUILD_DEPENDS</varname>
- definition: </para>
+ definition:</para>
<programlisting>BUILD_DEPENDS+= autoconf-2.13:../../devel/autoconf</programlisting>
</listitem>
<listitem>
- <para> If your package needs a library with which to link and
+ <para>If your package needs a library with which to link and
again there is no <filename>buildlink3.mk</filename> file
available, this is specified using the
<varname>DEPENDS</varname> definition. An example of this
is the <pkg>print/lyx</pkg> package, which uses the xpm
- library, version 3.4j to build: </para>
+ library, version 3.4j to build:</para>
<programlisting>DEPENDS+= xpm-3.4j:../../graphics/xpm</programlisting>
- <para> You can also use wildcards in package dependences:
- </para>
+ <para>You can also use wildcards in package dependences:
+</para>
<programlisting>DEPENDS+= xpm-[0-9]*:../../graphics/xpm</programlisting>
- <para> Note that such wildcard dependencies are retained when
+ <para>Note that such wildcard dependencies are retained when
creating binary packages. The dependency is checked when
installing the binary package and any package which matches
the pattern will be used. Wildcard dependencies should be
- used with care. </para>
+ used with care.</para>
- <para> The <quote>-[0-9]*</quote> should be used instead of
+ <para>The <quote>-[0-9]*</quote> should be used instead of
<quote>-*</quote> to avoid potentially ambiguous matches
such as <quote>tk-postgresql</quote> matching a
- <quote>tk-*</quote> <varname>DEPENDS</varname>. </para>
+ <quote>tk-*</quote> <varname>DEPENDS</varname>.</para>
<para>Wildcards can also be used to specify that a package
will only build against a certain minimum version of a
- pre-requisite: </para>
+ pre-requisite:</para>
<programlisting>DEPENDS+= tiff>=3.5.4:../../graphics/tiff</programlisting>
- <para> This means that the package will build against version
+ <para>This means that the package will build against version
3.5.4 of the tiff library or newer. Such a dependency may
be warranted if, for example, the API of the library has
changed with version 3.5.4 and a package would not compile
- against an earlier version of tiff. </para>
+ against an earlier version of tiff.</para>
- <para> Please note that such dependencies should only be
+ <para>Please note that such dependencies should only be
updated if a package requires a newer pre-requisite, but
not to denote recommendations such as security updates or
ABI changes that do not prevent a package from building
correctly. Such recommendations can be expressed using
- <varname>RECOMMENDED</varname>: </para>
+ <varname>RECOMMENDED</varname>:</para>
<programlisting>RECOMMENDED+= tiff>=3.6.1:../../graphics/tiff</programlisting>
- <para> In addition to the above <varname>DEPENDS</varname>
+ <para>In addition to the above <varname>DEPENDS</varname>
line, this denotes that while a package will build against
tiff>=3.5.4, at least version 3.6.1 is recommended.
<varname>RECOMMENDED</varname> entries will be turned into
dependencies unless explicitly ignored (in which case a
- warning will be printed). </para>
+ warning will be printed).</para>
<para>To ignore these dependency recommendations and just
use the required <varname>DEPENDS</varname>, set
@@ -231,92 +231,92 @@
very carefully; it is not very good as a general-purpose
hammer. If you use it, you need to be mindful of possible
ABI changes, including those from the underlying OS.
- </para>
+</para>
- <para> Packages that are built with recommendations ignored
+ <para>Packages that are built with recommendations ignored
may not be uploaded to ftp.NetBSD.org by developers and
should not be used across different systems that may have
- different versions of binary packages installed. </para>
+ different versions of binary packages installed.</para>
- <para> For security fixes, please update the package
+ <para>For security fixes, please update the package
vulnerabilities file as well as setting
<varname>RECOMMENDED</varname>, see <xref
linkend="security-handling"/> for more
Home |
Main Index |
Thread Index |
Old Index