A number of misc changes, a revamp of chapter 17, place-holder for
new "project goals" document.
This commit is contained in:
Jordan K. Hubbard
parent
e6120a759b
commit
36c1a880e4
Notes:
svn2git
2020-12-08 03:00:23 +00:00
svn path=/head/; revision=181
7 changed files with 194 additions and 124 deletions
|
|
@ -1,9 +1,9 @@
|
|||
# $Id: Makefile,v 1.6 1995-10-14 21:49:43 jfieber Exp $
|
||||
# $Id: Makefile,v 1.7 1995-12-07 13:22:12 jkh Exp $
|
||||
|
||||
SRCS= authors.sgml basics.sgml bibliography.sgml boothelp.sgml
|
||||
SRCS+= booting.sgml contrib.sgml crypt.sgml ctm.sgml current.sgml dialup.sgml
|
||||
SRCS+= diskless.sgml dma.sgml eresources.sgml esdi.sgml
|
||||
SRCS+= firewalls.sgml glossary.sgml
|
||||
SRCS+= firewalls.sgml glossary.sgml goals.sgml
|
||||
SRCS+= handbook.sgml history.sgml hw.sgml install.sgml kerberos.sgml
|
||||
SRCS+= kernelconfig.sgml kerneldebug.sgml memoryuse.sgml
|
||||
SRCS+= mirrors.sgml nfs.sgml nutshell.sgml
|
||||
|
|
|
|||
9
handbook/goals.sgml
Normal file
9
handbook/goals.sgml
Normal file
|
|
@ -0,0 +1,9 @@
|
|||
<!-- $Id: goals.sgml,v 1.1 1995-12-07 13:22:13 jkh Exp $ -->
|
||||
<!-- The FreeBSD Documentation Project -->
|
||||
|
||||
<sect><heading>FreeBSD Project goals<label id="goals"></heading>
|
||||
|
||||
<p><em>Contributed by &a.jkh;</em>.
|
||||
|
||||
<p><em>Note: This section is under construction.</em>
|
||||
|
||||
|
|
@ -1,4 +1,4 @@
|
|||
<!-- $Id: handbook.sgml,v 1.36 1995-12-04 13:39:30 jfieber Exp $ -->
|
||||
<!-- $Id: handbook.sgml,v 1.37 1995-12-07 13:22:14 jkh Exp $ -->
|
||||
<!-- The FreeBSD Documentation Project -->
|
||||
|
||||
<!DOCTYPE linuxdoc PUBLIC "-//FreeBSD//DTD linuxdoc//EN" [
|
||||
|
|
@ -49,8 +49,20 @@ Web server">.
|
|||
<part><heading>Basics</heading>
|
||||
|
||||
<chapt><heading>Introduction</heading>
|
||||
<p>FreeBSD is a 4.4 BSD Lite based operating system for Intel
|
||||
architecture (x86) based PCs. For an overview of FreeBSD, see
|
||||
<ref id="nutshell" name="FreeBSD in a nutshell">. For a
|
||||
history of the project, read <ref id="history"
|
||||
name="a brief history of FreeBSD">. To see a description of the
|
||||
latest release, read <ref id="relnotes"
|
||||
name="about the current release">. If you're interested
|
||||
in contributing something to the FreeBSD project (code, equipment,
|
||||
sacks of unmarked bills), please see about <ref id="submitters"
|
||||
name="contributing to FreeBSD">.
|
||||
|
||||
&nutshell;
|
||||
&history;
|
||||
&goals;
|
||||
&relnotes;
|
||||
|
||||
&install;
|
||||
|
|
@ -59,7 +71,6 @@ Web server">.
|
|||
<chapt><heading>Installing applications</heading>
|
||||
<sect><heading>* Installing packages</heading>
|
||||
&ports;
|
||||
&porting;
|
||||
|
||||
<!-- ************************************************************ -->
|
||||
|
||||
|
|
@ -124,8 +135,8 @@ Web server">.
|
|||
&ctm;
|
||||
⊃
|
||||
&kerneldebug;
|
||||
&submitters;
|
||||
&troubleshooting;
|
||||
&submitters;
|
||||
|
||||
|
||||
<!-- ************************************************************ -->
|
||||
|
|
|
|||
|
|
@ -1,21 +1,30 @@
|
|||
<!-- $Id: porting.sgml,v 1.10 1995-12-04 17:58:44 jfieber Exp $ -->
|
||||
<!-- $Id: porting.sgml,v 1.11 1995-12-07 13:22:15 jkh Exp $ -->
|
||||
<!-- The FreeBSD Documentation Project -->
|
||||
|
||||
<sect><heading>Porting applications<label id="porting"></heading>
|
||||
<sect1><heading>Porting an existing piece of free software<label id="porting"></heading>
|
||||
|
||||
<p><em>Contributed by &a.jkh;, &a.gpalmer; and
|
||||
&a.asami;.<newline>19 August 1995.</em>
|
||||
|
||||
Here are the guidelines one should follow in
|
||||
creating a new port for FreeBSD 2.x . This documentation will
|
||||
change as this process is progressively refined, so watch
|
||||
this space for details. The <tt>${..}</tt>
|
||||
variable names you see in this document all refer to
|
||||
various user-overridable defaults used (and documented)
|
||||
by <tt>/usr/share/mk/bsd.port.mk</tt>. Please refer to
|
||||
that file for more details.
|
||||
<p>The porting of freely available software, while perhaps not as
|
||||
gratifying as developing your own from scratch, is still a vital part
|
||||
of FreeBSD's growth and of great usefulness to those who wouldn't
|
||||
otherwise know where to turn for it. All ported software is organized
|
||||
into a carefully organized hierarchy know as ``the ports collection''.
|
||||
The collection enables a new user to get a quick and complete overview
|
||||
of what's available for FreeBSD in an easy-to-compile form. It also
|
||||
saves considerable space by not actually containing the the majority
|
||||
of the sources being ported, but merely those differences required for
|
||||
running under FreeBSD.
|
||||
|
||||
<sect1>
|
||||
<p>What follows are some guidelines for creating a new port for
|
||||
FreeBSD 2.x . The <tt>${..}</tt> variable names you will
|
||||
see in this document all refer to various user-overridable defaults
|
||||
used (and documented) by <tt>/usr/share/mk/bsd.port.mk</tt>.
|
||||
Please refer to that file for more details on the inner workings of
|
||||
the ports collection.
|
||||
|
||||
<sect2>
|
||||
<heading>Before Starting the Port<label id="porting:starting"></heading>
|
||||
|
||||
<p>Note: Only a fraction of the overridable variables are
|
||||
|
|
@ -98,7 +107,7 @@
|
|||
screwed up and used it in the wrong place doesn't mean
|
||||
you should do so too.
|
||||
|
||||
<sect1>
|
||||
<sect2>
|
||||
<heading>Quick Porting</heading>
|
||||
|
||||
<p>This section tells you how to do a quick port. In many
|
||||
|
|
@ -114,7 +123,7 @@
|
|||
change something, you'll have to refer to the next section
|
||||
too.
|
||||
|
||||
<sect2>
|
||||
<sect3>
|
||||
<heading>Writing the Makefile</heading>
|
||||
|
||||
<p>The minimal <tt>Makefile</tt> would look something like this:
|
||||
|
|
@ -125,7 +134,7 @@
|
|||
# Date created: 5 December 1994
|
||||
# Whom: asami
|
||||
#
|
||||
# $Id: porting.sgml,v 1.10 1995-12-04 17:58:44 jfieber Exp $
|
||||
# $Id: porting.sgml,v 1.11 1995-12-07 13:22:15 jkh Exp $
|
||||
#
|
||||
|
||||
DISTNAME= oneko-1.1b
|
||||
|
|
@ -144,7 +153,7 @@
|
|||
automatically by CVS when the port is imported to our main
|
||||
ports tree.
|
||||
|
||||
<sect2>
|
||||
<sect3>
|
||||
<heading>Writing the description files</heading>
|
||||
|
||||
<p>There are three required description files that are
|
||||
|
|
@ -152,7 +161,7 @@
|
|||
They are <tt>COMMENT</tt>, <tt>DESCR</tt>, and
|
||||
<tt>PLIST</tt>, and reside in the <tt>pkg</tt> subdirectory.
|
||||
|
||||
<sect3>
|
||||
<sect4>
|
||||
<heading>COMMENT</heading>
|
||||
|
||||
<p>This is the one-line description of the port. It is
|
||||
|
|
@ -162,7 +171,7 @@
|
|||
A cat chasing a mouse all over the screen
|
||||
</verb></tscreen>
|
||||
|
||||
<sect3>
|
||||
<sect4>
|
||||
<heading>DESCR</heading>
|
||||
|
||||
<p>This is a longer description of the port. One to a few
|
||||
|
|
@ -186,7 +195,7 @@ the screen.
|
|||
asami@cs.berkeley.edu
|
||||
</verb></tscreen>
|
||||
|
||||
<sect3>
|
||||
<sect4>
|
||||
<heading>PLIST</heading>
|
||||
|
||||
<p>This file lists all the files installed by the port. It
|
||||
|
|
@ -206,13 +215,13 @@ lib/X11/oneko/cat2.xpm
|
|||
lib/X11/oneko/mouse.xpm
|
||||
</verb></tscreen>
|
||||
|
||||
<sect2>
|
||||
<sect3>
|
||||
<heading>Creating the checksum file</heading>
|
||||
|
||||
<p>Just type `<tt>make makesum</tt>'. The ports make rules
|
||||
will automatically generate the file <tt>files/md5</tt>.
|
||||
|
||||
<sect2>
|
||||
<sect3>
|
||||
<heading>Testing the port</heading>
|
||||
|
||||
<p>You should make sure that the port rules do exactly what
|
||||
|
|
@ -223,7 +232,7 @@ lib/X11/oneko/mouse.xpm
|
|||
<pkgname>.tgz</tt>' and see if everything re-appears
|
||||
and works correctly.
|
||||
|
||||
<sect2>
|
||||
<sect3>
|
||||
<heading>Submitting the port</heading>
|
||||
|
||||
<p>Now that you're happy with your port, the only thing
|
||||
|
|
@ -242,7 +251,7 @@ ftp://ftp.freebsd.org/pub/FreeBSD/incoming/
|
|||
FreeBSD contributors' on the FreeBSD Handbook and other
|
||||
files. Isn't that great?!? <tt>:)</tt>
|
||||
|
||||
<sect1>
|
||||
<sect2>
|
||||
<heading>Slow Porting</heading>
|
||||
|
||||
<p>Ok, so it wasn't that simple, and the port required some
|
||||
|
|
@ -250,7 +259,7 @@ ftp://ftp.freebsd.org/pub/FreeBSD/incoming/
|
|||
explain, step by step, how to modify it to get it to work with
|
||||
the ports paradigm.
|
||||
|
||||
<sect2>
|
||||
<sect3>
|
||||
<heading>How things work</heading>
|
||||
|
||||
<p>First, this is the sequence of events which occurs when the
|
||||
|
|
@ -347,7 +356,7 @@ ftp://ftp.freebsd.org/pub/FreeBSD/incoming/
|
|||
`<tt>make</tt>', let's go through the recommended steps to
|
||||
create the perfect port.
|
||||
|
||||
<sect2>
|
||||
<sect3>
|
||||
<heading>Getting the original sources</heading>
|
||||
|
||||
<p>Get the original sources (normally) as a compressed tarball
|
||||
|
|
@ -372,7 +381,7 @@ ftp://freefall.freebsd.org/pub/FreeBSD/LOCAL_PORTS/
|
|||
we have a way to handle these situations (see the
|
||||
description of <tt>${PATCHFILES}</tt> below).
|
||||
|
||||
<sect2>
|
||||
<sect3>
|
||||
<heading>Modifying the port</heading>
|
||||
|
||||
<p>Unpack a copy of the tarball in a private directory and
|
||||
|
|
@ -392,7 +401,7 @@ ftp://freefall.freebsd.org/pub/FreeBSD/LOCAL_PORTS/
|
|||
as possible for the end-user while using a minimum of disk
|
||||
space.
|
||||
|
||||
<sect2>
|
||||
<sect3>
|
||||
<heading>Patching</heading>
|
||||
|
||||
<p>In the preparation of the port, files that have been added
|
||||
|
|
@ -414,7 +423,7 @@ ftp://freefall.freebsd.org/pub/FreeBSD/LOCAL_PORTS/
|
|||
same file (e.g., patch-aa and patch-ab both changing
|
||||
<tt>${WRKSRC}</tt>/foobar.c).
|
||||
|
||||
<sect2>
|
||||
<sect3>
|
||||
<heading>Configuring</heading>
|
||||
|
||||
<p>Include any additional customization commands to your
|
||||
|
|
@ -423,7 +432,7 @@ ftp://freefall.freebsd.org/pub/FreeBSD/LOCAL_PORTS/
|
|||
can also do this as Makefile targets and/or scripts with the
|
||||
name <tt>pre-configure</tt> or <tt>post-configure</tt>.
|
||||
|
||||
<sect2>
|
||||
<sect3>
|
||||
<heading>Handling user input</heading>
|
||||
|
||||
<p>If your port requires user input to build, configure or
|
||||
|
|
@ -434,7 +443,7 @@ ftp://freefall.freebsd.org/pub/FreeBSD/LOCAL_PORTS/
|
|||
then <em>only</em> those ports requiring interaction are
|
||||
built).
|
||||
|
||||
<sect1>
|
||||
<sect2>
|
||||
<heading>Configuring the Makefile</heading>
|
||||
|
||||
<p>Configuring the Makefile is pretty simple, and again we
|
||||
|
|
@ -442,7 +451,7 @@ ftp://freefall.freebsd.org/pub/FreeBSD/LOCAL_PORTS/
|
|||
starting. Consider the following problems in sequence as
|
||||
you design your new Makefile:
|
||||
|
||||
<sect2>
|
||||
<sect3>
|
||||
<heading>The original source</heading>
|
||||
|
||||
<p>Does it live in <tt>${DISTDIR}</tt> as a standard
|
||||
|
|
@ -461,7 +470,7 @@ ftp://freefall.freebsd.org/pub/FreeBSD/LOCAL_PORTS/
|
|||
`<tt>do-extract</tt>' target to override the default, though
|
||||
this should be rarely, if ever, necessary.
|
||||
|
||||
<sect2>
|
||||
<sect3>
|
||||
<heading>DISTNAME</heading>
|
||||
<p>You should set <tt>${DISTNAME}</tt> to be the base
|
||||
name of your port. The default rules expect the
|
||||
|
|
@ -492,7 +501,7 @@ work/foozolix-1.0/
|
|||
extraction, and the rest will be just left in
|
||||
<tt>${DISTDIR}</tt> for later use.
|
||||
|
||||
<sect2>
|
||||
<sect3>
|
||||
<heading>CATEGORIES and KEYWORDS</heading>
|
||||
<p>When a package is created, it is put under
|
||||
<tt>/usr/ports/packages/All</tt> and links are made from one
|
||||
|
|
@ -513,7 +522,7 @@ work/foozolix-1.0/
|
|||
<tt>${CATEGORIES}</tt>. This is currently used only
|
||||
as a field of the <tt>/usr/ports/INDEX</tt> file.
|
||||
|
||||
<sect2>
|
||||
<sect3>
|
||||
<heading>MASTER_SITES</heading>
|
||||
<p>If you have a ftp-URL pointing at the the original tarball,
|
||||
record the directory containing the tarball in
|
||||
|
|
@ -531,7 +540,7 @@ work/foozolix-1.0/
|
|||
to add support for automatically determining the closest
|
||||
master site and fetching from there!
|
||||
|
||||
<sect2>
|
||||
<sect3>
|
||||
<heading>PATCHFILES</heading>
|
||||
<p>If your port requires some additional patches that are
|
||||
available by ftp, set <tt>${PATCHFILES}</tt> to the
|
||||
|
|
@ -550,16 +559,16 @@ work/foozolix-1.0/
|
|||
decompressed automatically if the filenames end with
|
||||
`<tt>.gz</tt>' or `<tt>.Z</tt>'.
|
||||
|
||||
<sect2>
|
||||
<sect3>
|
||||
<heading>MAINTAINER</heading>
|
||||
<p>Set your mail-address here. Please. <tt>:)</tt>
|
||||
|
||||
<sect2>
|
||||
<sect3>
|
||||
<heading>Dependencies</heading>
|
||||
<p>Many ports depend on other ports. There are five
|
||||
variables that you can use to ensure that all the required
|
||||
bits will be on the user's machine.
|
||||
<sect3>
|
||||
<sect4>
|
||||
<heading>LIB_DEPENDS</heading>
|
||||
<p>This variable specifies the shared libraries this port
|
||||
depends on. It is a list of `<tt>lib:dir</tt>' pairs
|
||||
|
|
@ -576,7 +585,7 @@ LIB_DEPENDS= tcl\\.7\\.:${PORTSDIR}/lang/tcl
|
|||
Note that the <tt>lib</tt> part is just an argument given
|
||||
to `<tt>ldconfig -r | grep</tt>', so periods should be
|
||||
escaped by two backslashes like in the example above.
|
||||
<sect3>
|
||||
<sect4>
|
||||
<heading>RUN_DEPENDS</heading>
|
||||
<p>This variable specifies executables this port depends on
|
||||
during run-time. It is a list of `<tt>exec:dir</tt>'
|
||||
|
|
@ -594,7 +603,7 @@ RUN_DEPENDS= wish:${PORTSDIR}/x11/tk
|
|||
target. Also, the name of the dependency is put in to the
|
||||
package so that <tt>pkg_add</tt> will automatically
|
||||
install it if it is not on the user's system.
|
||||
<sect3>
|
||||
<sect4>
|
||||
<heading>BUILD_DEPENDS</heading>
|
||||
<p>This variable specifies executables this port requires to
|
||||
build. Like <tt>RUN_DEPENDS</tt>, it is a list of
|
||||
|
|
@ -609,7 +618,7 @@ BUILD_DEPENDS= unzip:${PORTSDIR}/archivers/unzip
|
|||
Note that `build' here means everything from extracting to
|
||||
compilation. The dependency is checked from within the
|
||||
<tt>extract</tt> target.
|
||||
<sect3>
|
||||
<sect4>
|
||||
<heading>FETCH_DEPENDS</heading>
|
||||
<p>This variable specifies executables this port requires to
|
||||
fetch. Like the previous two, it is a list of
|
||||
|
|
@ -623,7 +632,7 @@ FETCH_DEPENDS= ncftp2:${PORTSDIR}/net/ncftp2
|
|||
|
||||
The dependency is checked from within the <tt>fetch</tt>
|
||||
target.
|
||||
<sect3>
|
||||
<sect4>
|
||||
<heading>DEPENDS</heading>
|
||||
<p>If there is a dependency that doesn't fall into either of
|
||||
the above four categories, or your port requires to have
|
||||
|
|
@ -632,7 +641,7 @@ FETCH_DEPENDS= ncftp2:${PORTSDIR}/net/ncftp2
|
|||
just a list of directories, as there is nothing to check,
|
||||
unlike the previous two.
|
||||
|
||||
<sect2>
|
||||
<sect3>
|
||||
<heading>Building mechanisms</heading>
|
||||
<p>If your package uses GNU <tt>make</tt>, set
|
||||
`<tt>USE_GMAKE=yes</tt>'. If your package uses GNU
|
||||
|
|
@ -654,14 +663,14 @@ FETCH_DEPENDS= ncftp2:${PORTSDIR}/net/ncftp2
|
|||
<tt>${ALL_TARGET}</tt> accordingly. Same goes for
|
||||
`<tt>install</tt>' and <tt>${INSTALL_TARGET}</tt>.
|
||||
|
||||
<sect2>
|
||||
<sect3>
|
||||
<heading>NO_INSTALL_MANPAGES</heading>
|
||||
<p>If the port uses imake but doesn't understand the
|
||||
`<tt>install.man</tt>' target,
|
||||
`<tt>NO_INSTALL_MANPAGES=yes</tt>' should be set. In
|
||||
addition, the author of the original port should be shot.
|
||||
|
||||
<sect1>
|
||||
<sect2>
|
||||
<heading>Licensing Problems</heading>
|
||||
<p>Some software packages have restrictive licenses or are in
|
||||
violation to the law (PKP's patent on public key crypto,
|
||||
|
|
@ -688,17 +697,17 @@ FETCH_DEPENDS= ncftp2:${PORTSDIR}/net/ncftp2
|
|||
<p>Note: If you are a committer, make sure you update the
|
||||
<tt>ports/LEGAL</tt> file too.
|
||||
|
||||
<sect1>
|
||||
<sect2>
|
||||
<heading>* Upgrading</heading>
|
||||
<p>This section is still under construction, sorry.
|
||||
|
||||
<sect1>
|
||||
<sect2>
|
||||
<heading>Do's and Dont's</heading>
|
||||
|
||||
<p>Here's a list of common do's and dont's that you encounter
|
||||
during the porting process.
|
||||
|
||||
<sect2>
|
||||
<sect3>
|
||||
<heading>WRKDIR</heading>
|
||||
<p>Don't leave anything valuable lying around in the
|
||||
`<tt>work</tt>' subdirectory, `<tt>make clean</tt>' will
|
||||
|
|
@ -707,14 +716,14 @@ FETCH_DEPENDS= ncftp2:${PORTSDIR}/net/ncftp2
|
|||
`<tt>files</tt>' and use the <tt>post-extract</tt> target to
|
||||
copy them to the `<tt>work</tt>' subdirectory.
|
||||
|
||||
<sect2>
|
||||
<sect3>
|
||||
<heading>Package information</heading>
|
||||
<p>Do install package information, i.e., the three files in
|
||||
<tt>pkg</tt>. Note that these files are not used only for
|
||||
packaging anymore, and are <em>mandatory</em> now, even if
|
||||
<tt>${NO_PACKAGE}</tt> is set.
|
||||
|
||||
<sect2>
|
||||
<sect3>
|
||||
<heading>Compress manpages, strip binaries</heading>
|
||||
<p>Do compress manpages and strip binaries. If the original
|
||||
source already does that, fine; otherwise, you can add a
|
||||
|
|
@ -734,7 +743,7 @@ FETCH_DEPENDS= ncftp2:${PORTSDIR}/net/ncftp2
|
|||
to check whether the binary is stripped or not. If it
|
||||
doesn't say `not stripped', it is stripped.
|
||||
|
||||
<sect2>
|
||||
<sect3>
|
||||
<heading>Custom utilities</heading>
|
||||
<p>Don't rely on custom utilities in your local configure
|
||||
script or anything -- they may not be there on the user's
|
||||
|
|
@ -755,14 +764,14 @@ FETCH_DEPENDS= ncftp2:${PORTSDIR}/net/ncftp2
|
|||
`<tt>make</tt>' and have that port, as well as everything it
|
||||
requires, built automatically.
|
||||
|
||||
<sect2>
|
||||
<sect3>
|
||||
<heading>Feedback</heading>
|
||||
<p>Do send applicable changes/patches to the original
|
||||
author/maintainer for inclusion in next release of the code.
|
||||
This will only make your job that much easier for the next
|
||||
release.
|
||||
|
||||
<sect2>
|
||||
<sect3>
|
||||
<heading>RCS strings</heading>
|
||||
<p>Don't put RCS strings in patches. CVS will mangle them
|
||||
when we put the files into the ports tree, and when we check
|
||||
|
|
@ -771,7 +780,7 @@ FETCH_DEPENDS= ncftp2:${PORTSDIR}/net/ncftp2
|
|||
(`<tt>$</tt>') signs, and typically start with
|
||||
`<tt>$Id</tt>' or `<tt>$RCS</tt>'.
|
||||
|
||||
<sect2>
|
||||
<sect3>
|
||||
<heading>Recursive diff</heading>
|
||||
<p>Using the recurse (`<tt>-r</tt>') option to <tt>diff</tt>
|
||||
to generate patches is fine, but please take a look at the
|
||||
|
|
@ -783,7 +792,7 @@ FETCH_DEPENDS= ncftp2:${PORTSDIR}/net/ncftp2
|
|||
<tt>post-extract</tt> target rather than as part of the
|
||||
patch.
|
||||
|
||||
<sect2>
|
||||
<sect3>
|
||||
<heading>PREFIX</heading>
|
||||
<p>Do try to make your port install relative to
|
||||
<tt>${PREFIX}</tt> in your Makefiles. This will
|
||||
|
|
@ -801,7 +810,7 @@ FETCH_DEPENDS= ncftp2:${PORTSDIR}/net/ncftp2
|
|||
of <tt>${PREFIX}</tt> unless the package is one that
|
||||
hard-codes itself to a compiled-in location.
|
||||
|
||||
<sect2>
|
||||
<sect3>
|
||||
<heading>Subdirectories</heading>
|
||||
<p>Try to let the port put things in the right subdirectories
|
||||
of <tt>${PREFIX}</tt>. Some ports lump everything
|
||||
|
|
@ -818,7 +827,7 @@ FETCH_DEPENDS= ncftp2:${PORTSDIR}/net/ncftp2
|
|||
<tt>/usr</tt> pretty much applies to <tt>/usr/local</tt>
|
||||
too.
|
||||
|
||||
<sect2>
|
||||
<sect3>
|
||||
<heading>ldconfig</heading>
|
||||
<p>If your port installs a shared library, add a
|
||||
<tt>post-install</tt> target to your Makefile that runs
|
||||
|
|
@ -851,7 +860,7 @@ lib/libtcl.so.7.3
|
|||
eternally rot to death in the deepest bowels of hell (not
|
||||
necessarily in that order)....
|
||||
|
||||
<sect2>
|
||||
<sect3>
|
||||
<heading>If you are stuck....</heading>
|
||||
<p>Do look at existing examples and the <tt>bsd.port.mk</tt>
|
||||
file before asking us questions! <tt>;)</tt>
|
||||
|
|
@ -859,7 +868,7 @@ lib/libtcl.so.7.3
|
|||
<p>Do ask us questions if you have any trouble! Don't just
|
||||
beat your head against a wall! <tt>:)</tt>
|
||||
|
||||
<sect1>
|
||||
<sect2>
|
||||
<heading>A Sample Makefile</heading>
|
||||
<p>Here is a sample Makefile that you can use to create a new
|
||||
port. Make sure you remove all the extra comments (ones
|
||||
|
|
@ -880,7 +889,7 @@ lib/libtcl.so.7.3
|
|||
person who wrote this Makefile]
|
||||
# Whom: Satoshi Asami <asami@FreeBSD.ORG>
|
||||
#
|
||||
# $Id: porting.sgml,v 1.10 1995-12-04 17:58:44 jfieber Exp $
|
||||
# $Id: porting.sgml,v 1.11 1995-12-07 13:22:15 jkh Exp $
|
||||
[ ^^^^ don't worry about this...it will be automatically filled in by CVS when
|
||||
it is committed to our repository]
|
||||
#
|
||||
|
|
@ -943,7 +952,7 @@ lib/libtcl.so.7.3
|
|||
.include <bsd.port.mk>
|
||||
</verb></tscreen>
|
||||
|
||||
<sect1>
|
||||
<sect2>
|
||||
<heading>Package Names</heading>
|
||||
|
||||
<p>The following are the conventions you should follow in
|
||||
|
|
@ -998,7 +1007,7 @@ xvgr-2.10pl1 xvgr-2.10.1 `pl' allowed only when no maj/minor numbers
|
|||
original author or use the date string (`yy.mm.dd') as the
|
||||
version.
|
||||
|
||||
<sect1>
|
||||
<sect2>
|
||||
<heading>That's It, Folks!</heading>
|
||||
|
||||
<p>Boy, this sure was a long tutorial, wasn't it? Thanks for
|
||||
|
|
|
|||
|
|
@ -1,11 +1,11 @@
|
|||
<!-- $Id: relnotes.sgml,v 1.7 1995-11-20 01:10:28 jfieber Exp $ -->
|
||||
<!-- $Id: relnotes.sgml,v 1.8 1995-12-07 13:22:16 jkh Exp $ -->
|
||||
<!-- The FreeBSD Documentation Project -->
|
||||
|
||||
<!--
|
||||
<!DOCTYPE linuxdoc PUBLIC '-//FreeBSD//DTD linuxdoc//EN'>
|
||||
<linuxdoc><book><chapt>foo
|
||||
-->
|
||||
<sect><heading>About this release<label id="relnotes"></heading>
|
||||
<sect><heading>About the current release<label id="relnotes"></heading>
|
||||
|
||||
<p>FreeBSD is a freely available, full source 4.4 BSD
|
||||
Lite based release for Intel i386/i486/Pentium (or
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
<!-- $Id: sections.sgml,v 1.6 1995-10-14 21:49:54 jfieber Exp $ -->
|
||||
<!-- $Id: sections.sgml,v 1.7 1995-12-07 13:22:17 jkh Exp $ -->
|
||||
<!-- The FreeBSD Documentation Project -->
|
||||
|
||||
<!-- Entities containing all the pieces of the handbook are -->
|
||||
|
|
@ -17,6 +17,7 @@
|
|||
<!ENTITY eresources SYSTEM "eresources.sgml">
|
||||
<!ENTITY esdi SYSTEM "esdi.sgml">
|
||||
<!ENTITY firewalls SYSTEM "firewalls.sgml">
|
||||
<!ENTITY goals SYSTEM "goals.sgml">
|
||||
<!ENTITY glossary SYSTEM "glossary.sgml">
|
||||
<!ENTITY history SYSTEM "history.sgml">
|
||||
<!ENTITY hw SYSTEM "hw.sgml">
|
||||
|
|
|
|||
|
|
@ -1,46 +1,96 @@
|
|||
<!-- $Id: submitters.sgml,v 1.8 1995-10-07 04:32:03 jfieber Exp $ -->
|
||||
<!-- $Id: submitters.sgml,v 1.9 1995-12-07 13:22:18 jkh Exp $ -->
|
||||
<!-- The FreeBSD Documentation Project -->
|
||||
|
||||
<chapt><heading>Contributing to FreeBSD<label id="submitters"></heading>
|
||||
|
||||
<p><em>Contributed by &a.jkh;.</em>
|
||||
|
||||
This guide is intended for those who are moderately familiar with
|
||||
FreeBSD and have reached a point where they have some locally
|
||||
developed customizations or fixes to the system which they'd like to
|
||||
incorporate back into the mainstream sources. Submitting something to
|
||||
the FreeBSD project ensures that you won't have to continually
|
||||
reintegrate it with each subsequent release and is also an excellent
|
||||
way of getting your code seriously <em>tested</em>! Many people have
|
||||
seen an original concept develop far beyond what they might have
|
||||
originally envisioned simply due to the flood of feedback and ideas
|
||||
generated by the many thousands of users of FreeBSD. Contributions
|
||||
are also what FreeBSD lives and grows from, so your contributions are
|
||||
very important to the continued survival of this communal effort of
|
||||
ours---we're very glad to see you reading this document!
|
||||
<p>So you want to contribute something to FreeBSD? That's great!
|
||||
We can always use the help, and FreeBSD is one of those systems
|
||||
that <em>relies</em> on the contributions of its user base in order
|
||||
to survive. Your contributions are not only appreciated, they're
|
||||
vital to FreeBSD's continued growth!
|
||||
|
||||
Submissions to FreeBSD can generally be classified into four categories:
|
||||
<p>Contrary to what some people might also have you believe, you don't
|
||||
need to be a hot-shot programmer or a close personal friend of the
|
||||
FreeBSD core team in order to have your contributions accepted. The
|
||||
FreeBSD Project's development is done by a large and growing number of
|
||||
international contributors who's ages and areas of technical expertise
|
||||
vary greatly, and there is always more work to be done than there are
|
||||
people available to do it.
|
||||
|
||||
<p>Since the FreeBSD project is responsible for an entire operating
|
||||
system environment (and its installation) rather than just a kernel or
|
||||
a few scattered utilities, our "TODO" list also spans a very wide
|
||||
range of tasks, from documentation, beta testing and presentation to
|
||||
highly specialized types of kernel development. No matter what your
|
||||
skill level, there's almost certainly something you can do to help the
|
||||
project!
|
||||
|
||||
<p>Commmercial entities engaged in FreeBSD-related enterprises are
|
||||
also encouraged to contact us. Need a special extention to make your
|
||||
product work? You'll find us receptive to your requests, given that
|
||||
they aren't too outlandish. Working on a value-added product? Please
|
||||
let us know! We may be able to work cooperatively on some aspect of
|
||||
it. The free software world is challenging a lot of existing
|
||||
assumptions about how software is developed, sold, and maintained
|
||||
throughout its life cycle, and we urge you to at least give it a
|
||||
second look.
|
||||
|
||||
<sect><heading>What's needed</heading>
|
||||
|
||||
<p>The following list of tasks and sub-projects represents something
|
||||
of an amalgam of the various core team TODO lists and user requests
|
||||
we've collected over the last couple of months. Where possible, tasks
|
||||
have been ranked by degree of urgency. If you're interested in
|
||||
working on one of the tasks you see here, send mail to the coordinator
|
||||
listed by clicking on their names. If no coordinator has been
|
||||
appointed, maybe you'd like to volunteer?
|
||||
|
||||
<sect1><heading>Urgently needed</heading>
|
||||
<p>The following tasks are considered to be urgent, usually because
|
||||
they represent something that is badly broken:
|
||||
<enum>
|
||||
<item>Ideas, general suggestions, bug reports.
|
||||
<item>Changes to existing sources.
|
||||
<item>Significant contribution of a large body of independent work.
|
||||
<item>Porting of freely available software.
|
||||
<item>Fix the DOS file system. Coordinator: <tt><htmlurl
|
||||
url="mailto:hackers@freebsd.org" name="Hackers (no coordinator)"></tt>.
|
||||
<item>Fix the union file system. Coordinator: <tt><htmlurl
|
||||
url="mailto:dyson@freebsd.org" name="John Dyson"></tt>
|
||||
</enum>
|
||||
A submission in <em>any</em> of these categories is highly welcomed as they
|
||||
are each, in their own way, quite significant to the project.
|
||||
|
||||
<sect1><heading>Not urgently needed</heading>
|
||||
<p>The following tasks need to be done, but not with any particular
|
||||
urgency:
|
||||
<enum>
|
||||
<item>Put something here.
|
||||
</enum>
|
||||
|
||||
<sect><heading>Ideas and suggestions</heading>
|
||||
<sect1><heading>Would be nice to have</heading>
|
||||
<p>The following tasks are purely cosmetic or represent such an
|
||||
investment or work that it's not likely that anyone will get them done
|
||||
anytime soon:
|
||||
|
||||
<enum>
|
||||
<item>Put something here too.
|
||||
</enum>
|
||||
|
||||
<sect><heading>How to contribute</heading>
|
||||
|
||||
<p>Contributions to the system generally fall into one or more of
|
||||
the following 5 categories:
|
||||
|
||||
<sect1><heading>Bug reports and general commentary</heading>
|
||||
<p>If you have a bug to report or a suggestion to make:
|
||||
|
||||
<p>An idea, suggestion or fix can be communicated in one of the following ways:
|
||||
<itemize>
|
||||
<item>An idea or suggestion of general technical interest should be
|
||||
mailed to <tt><hackers@freebsd.org></tt>.
|
||||
mailed to <tt><htmlurl url="mailto:hackers@freebsd.org"
|
||||
name="<hackers@freebsd.org>"></tt>.
|
||||
Likewise, people with an interest
|
||||
in such things (and a tolerance for a <em>high</em>
|
||||
volume of mail!) may
|
||||
subscribe to the hackers mailing list by sending mail to
|
||||
<tt><majordomo@freebsd.org></tt>.
|
||||
<tt><htmlurl url="mailto:majordomo@freebsd.org"
|
||||
name="<majordomo@freebsd.org>"></tt>.
|
||||
See <ref id="eresources:mail" name="mailing lists">
|
||||
for more information about this and other mailing lists.
|
||||
|
||||
|
|
@ -56,10 +106,19 @@ are each, in their own way, quite significant to the project.
|
|||
a week, depending on your email connection) or are, for some
|
||||
reason, unable to use the <tt>send-pr(1)</tt> command,
|
||||
then you may also file a bug report by sending mail to
|
||||
<tt><bugs@freebsd.org></tt>.
|
||||
<tt><htmlurl url="mailto:bugs@freebsd.org"
|
||||
name="<bugs@freebsd.org>"></tt>.
|
||||
</itemize>
|
||||
|
||||
<sect><heading>Changes to the existing code</heading>
|
||||
<sect1><heading>Changes to the documentation</heading>
|
||||
|
||||
<p>Changes to the documentation are overseen by the FreeBSD Documentation
|
||||
Project, which can be reached at <tt><htmlurl url="mailto:doc@freebsd.org"
|
||||
name="<doc@freebsd.org>"></tt>. This does not generally include
|
||||
changes to manual pages, which should be considered under the category
|
||||
of "changes to existing source code."
|
||||
|
||||
<sect1><heading>Changes to existing source code</heading>
|
||||
|
||||
<p>An addition or change to the existing source code is a somewhat trickier
|
||||
affair and depends a lot on how far out of date you are with the current
|
||||
|
|
@ -96,7 +155,8 @@ diff -c -r olddir newdir
|
|||
<tt>patch(1)</tt> command), you should bundle them up in an
|
||||
email message and send it, along with a brief description of
|
||||
what the diffs are for, to
|
||||
<tt><hackers@freebsd.org></tt>. Someone will very
|
||||
<tt><htmlurl url="mailto:hackers@freebsd.org"
|
||||
name="<hackers@freebsd.org>"></tt>. Someone will very
|
||||
likely get back in touch with you in 24 hours or less,
|
||||
assuming of course that your diffs are interesting! :-)
|
||||
|
||||
|
|
@ -105,22 +165,23 @@ diff -c -r olddir newdir
|
|||
then you may be better off bundling any new files, diffs and
|
||||
instructions for deleting/renaming others into a <tt>tar</tt>
|
||||
file and running the <tt>uuencode(1)</tt> program on it before
|
||||
sending the output of that to <tt><hackers@freebsd.org></tt>.
|
||||
sending the output of that to <tt><htmlurl url="mailto:hackers@freebsd.org"
|
||||
name="<hackers@freebsd.org>"></tt>.
|
||||
See the man pages on <tt>tar(1)</tt> and <tt>uuencode(1)</tt> for more
|
||||
information on bundling files this way.
|
||||
|
||||
If your change is of a potentially sensitive nature, e.g.
|
||||
you're unsure of copyright issues governing its further distribution
|
||||
or you're simply not ready to release it without a tighter review first,
|
||||
then you should send it to <tt><core@freebsd.org></tt> rather than
|
||||
then you should send it to <tt><htmlurl url="mailto:core@freebsd.org"
|
||||
name="<core@freebsd.org>"></tt> rather than
|
||||
<tt><hackers@freebsd.org></tt>. The core mailing list
|
||||
reaches a much smaller group of people who do much of the
|
||||
day-to-day work on FreeBSD. Note that this group is also
|
||||
<em>very busy</em> and so you should only send mail to them
|
||||
in cases where mailing to hackers is truly impractical.
|
||||
|
||||
|
||||
<sect><heading>Contributions of new code</heading>
|
||||
<sect1><heading>Contributions of new code</heading>
|
||||
|
||||
<p>In the case of a significant contribution of a large body
|
||||
work, or the addition of an important new feature to FreeBSD,
|
||||
|
|
@ -193,30 +254,9 @@ THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
|
|||
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
|
||||
THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
|
||||
|
||||
$Id: submitters.sgml,v 1.8 1995-10-07 04:32:03 jfieber Exp $
|
||||
$Id: submitters.sgml,v 1.9 1995-12-07 13:22:18 jkh Exp $
|
||||
</verb></tscreen>
|
||||
For your convenience, a copy of this text can be found in
|
||||
<tt>/usr/share/examples/etc/bsd-style-copyright</tt>.
|
||||
|
||||
|
||||
<sect><heading>Porting of software</heading>
|
||||
|
||||
<p>The porting of freely available software, while perhaps not as
|
||||
gratifying as developing your own from scratch, is still a vital part
|
||||
of FreeBSD's growth and of great usefulness to those who wouldn't
|
||||
otherwise know where to turn for it. All ported software is organized
|
||||
into a carefully organized hierarchy know as ``the ports collection''.
|
||||
The collection enables a new user to get a quick and complete overview
|
||||
of what's available for FreeBSD in an easy-to-compile form. It also
|
||||
saves considerable space by not actually containing the the majority
|
||||
of the sources being ported, but merely those differences required for
|
||||
running under FreeBSD. See <ref id="ports" name="The ports
|
||||
collection"> for more information on using the ports collection and
|
||||
<ref id="porting" name="Porting applications"> for guidelines on
|
||||
creating new ports. You may also send mail to
|
||||
<tt><ports@freebsd.org></tt>.
|
||||
|
||||
Whichever way you decide to contribute, we hope you'll find it an
|
||||
enjoyable and rewarding process. Such contributions are also very
|
||||
valuable to FreeBSD's continued progress, and as a free software
|
||||
effort, the more we all put in the more we all get back out of it!
|
||||
&porting;
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue